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WELCOME TO MODULE 4- 
CODING THE PROGRAM: 
HIGH-LEVEL LANGUAGES 


Now you are ready for some real adventure! In this module, you will 
advance from the design stage to the actual program coding process. 


You will be shown program coding examples in BASIC, FORTRAN, COBOL, C, and 
PASCAL. Also, for your convenience, you will receive a pad of generic 
programming forms to assist you in your personal programming exercises. 


The interactive diskette enclosed with Module 4 contains an expanded 
version of the checkbook register program. I am certain you will want to 
review this program to compare "our" version of the program with "your" 
version, developed since Module 3! 


We have also included a bonus program, "TEXTMASTER," on this month's 
diskette. Please see the enclosed cover letter for additional information on 
this word processing program. 


Next month, you will continue your work in program coding with Module 5 -- 


Coding the Program: Assembly Language. This upcoming module will explore the 
actual machine language used by your computer and a closely related programming 
language called "assembly language." It will also include a machine-language 
monitor program to let you enter, test, examine, and modify existing program 
code, as well as an assembler program that will allow you to create assembly - 
language programs of your own. 


We are certain that you will enjoy the bonus program TEXTMASTER -- and 
it's just part of the experiences packed in Module 4. 


Thanks again for your participation in the Series. We will continue to 
make each module an exciting educational experience. 


Sincerely, 


Fim p Brge 


Project Engineer 
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Overview for the Commodore 64 and 128 Computers 


CONTEMPORARY 
PROGRAMMING 
AND SOFTWARE 
DESIGN SERIES 


Module 4 in McGraw-Hill’s Contemporary Pro- 
gramming and Software Design Series takes you 
from the paper design stage of programming to the 
actual coding stage. This is where you actually enter 
your program into the computer, using a language 
that the computer will understand. In this module, 
we will deal with high-level languages such as 
FORTRAN, BASIC, COBOL, and Pascal. We will 
also see some program examples in C and FORTH. 

As in previous modules, our demonstration 
programs on the enclosed disk are written in 
BASIC, since the other languages are not neces- 
sarily available to all computer users. However, 
program examples are provided in other languages, 
and you may at any time wish to try out a program 
segment in a language that you have available. 

The enclosed program disk has more than just 
BASIC program files on it. You will also find some 
data files. You are welcome to back them up (in 
fact, you are encouraged to do so), as a guard 
against accidents. However, as before, all BASIC 
programs and data files must be available on Drive 
8 when they are needed. 

Now, let’s go on to the process of Coding the 
Program, in the enclosed Module 4. As before, the 
demonstration programs are written in BASIC, 
since that is the one language we can be sure that 
everyone has in both the C64 and 128. To begin, 
type in the commanas: 


LOAD “WELCOME” 8 <return> 
RUN <return> 


and you will be on your way. When your computer 
directs you to return to your Learning Guide, turn 
to the Introduction to begin your experience of 
Coding the Program, using high-level languages. 

One more program on your Program Disk, 
TEXTMASTER, is a word processor program 
which you may LOAD and RUN whenever you like. 
As explained in the initial message it places on the 
screen, it may be freely shared and distributed. 
However, you may not charge for it. No separate 
documentation is available for this program, but it is 
menu driven and will lead you through any neces- 
sary commands. Simply press (fl) to return to the 
command menu. 

We hope that this program will be of service to 
you in using your computer. 


Na 
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CODING THE PROGRAM: 
HIGH-LEVEL LANGUAGES 


The initial design phase of the programming pro- 
cess begins with the original idea or concept for a 
problem to be solved by the computer. It includes 
the definition of the problem and its solution, and 
the charting or diagramming of the solution 
procedure. But once the final chart or diagram has 
been drawn, the initial design phase is at an end. 

The initial design phase is carried out entirely on 
paper and it is utterly independent of the computer 
used and the programming language used on the 
computer. (It is sometimes helpful to take these 
factors into account when you are charting the 
solution, so that you can take advantage of any 
special features available, but it is not necessary to 
do so.) 
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The next step in the programming process does 
require that the specific language and computer be 
known. Depending on the method of program entry 
used, the computer itself may need to be available 
for use. Certainly this is true of any single-user 
personal computer. 

This is the point at which we must actually write 
the program the computer will execute. We do this 
by rewriting each step in the final flowchart or 
diagram, in order, as one or more computer 
instructions. Then we can proceed to run and test 
the resulting computer program. 

The process of rewriting the flowchart or diagram 
as an actual computer program is known as coding. 
This is the process of turning a graphic solution 


Coding the Program 


DEFINING 


DEFINING 
THE a a = 
SOLUTION 


PROBLEM 


DEBUGGING 
THE 
PROGRAM 


procedure into a series of instructions that the com- 
puter can understand and execute. As we show in 
Figure 0-1, coding is Step 4 in the seven-step pro- 
gramming process. 

Actually, the Central Processing Unit, or “brain” 
of the computer (a microprocessor IC in microcom- 
puters) only understands its own machine lan- 
guage, which consists of binary Os and 1s arranged 
in a very specific sequence. But it is very difficult to 
keep track of how many binary digits, or bits, you 
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Figure 0-1. The general programming process. 


have written down, to say nothing of their correct 
order. To avoid this problem, a number of com- 
puter languages have been developed. As shown in 
Figure 0-2, these languages are said to be on one 
of two levels. 

The simplest language is known as assembly lan- 
guage. This type of language is specific to the proc- 
essor itself, and corresponds directly to the 
processor’s machine language. All it does is replace 
the binary instruction codes with ASCII letter 
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sequences that more clearly describe and suggest 
the operation being specified. Assembly language 
also permits data and memory locations to be de- 
fined in terms of symbols, rather than as absolute 
binary addresses. Nevertheless, there is a basic one- 
to-one correlation between the assembly language 
and its equivalent machine code. Therefore, as- 
sembly language is known as a low-level language. 

More complex languages permit groups of ma- 
chine instructions to be defined and executed with 
a single instruction line. Such languages are known 
as high-level languages, and are used somewhat 
differently from assembly language. These are such 
languages as BASIC, FORTRAN, COBOL, 
ALGOL, and FORTH (and many more). 

Because these languages use a single line of pro- 
gram code to specify a group of machine language 
instructions, they are easier to use and to learn 
than assembly language. Therefore, we will begin 
our study of coding with these high-level lan- 
guages. We will learn about assembly languages in 
a later module. 

If you have not already done so, turn on your 
computer and disk drive(s), and insert your Pro- 
gram Disk in Drive 8. Then, type in the following 
commands: 


LOAD "WELCOME”,8 <return> 
RUN <return> 


Proceed to Track 1 when your computer directs 
you to do so. 
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‘Figure 0-2. The concept of coding. 
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NOTES: 
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KINDS OF HIGH-LEVEL LANGUAGES 


Because each instruction in a high-level language 
specifies a sequence of machine language instruc- 
tions, the sequence is predefined as an inherent 
part of the high-level language. That is, each time 
you enter a given instruction or command in a 
given language, that language will substitute the 
exact same series of machine instructions. The spe- 
cific operands for the instructions may change, but 
the instructions themselves will not. 

The problem with a predefined sequence of in- 
structions is that it must be optimized ahead of time 
for a particular kind of program operation. Other 
kinds of operations may be possible for the lan- 
guage, but they will not operate as well as the proc- 
essor could manage them, since the selected 
sequence of operations was optimized for other 
kinds of operations. 

What this means is that you, as the programmer, 
must select the desired programming language ac- 
cording to the kind of task that your program is to 
perform. Otherwise, the resulting program may be 
inefficient and clumsy, or even impossible. To see 
why this is so, let’s take a look at a number of 
common programming languages and explore their 
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characteristics, advantages, and disadvantages with 
respect to each other. 


Sector 1: Interpreted Languages 


High-level languages may be classified in many dif- 
ferent ways. One of the more useful classifications 
involves the distinction between interpreted 
languages and compiled languages. A program 
written in an interpreted language will remain in its 
high-level form in the computer’s memory. Then, a 
program called an interpreter, which is also present 
in memory, scans the user program and executes 
machine-language routines in accordance with the 
user program. The machine-language routines are 
part of the interpreter and remain there. The high- 
level user program remains unchanged. 

On the other hand, a compiler language involves 
an intermediate step. The high-level user program 
is first scanned by a special program called a com- 
piler. The compiler actually translates the high-level 
program into machine code and produces a 
machine-language program as its output. The 
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machine-language program performs the same task 
as the high-level program. However, it no longer 
requires the compiler. Instead, the machine code 
can be loaded into the computer and executed at 
any desired time. 

The most familiar of the interpreted languages is 
BASIC, which we are using for most of our program 
examples. Many computers, including the Com- 
modore 64, start up in BASIC. Newer computers, 
such as the IBM PC and compatibles, start up in the 
operating system, and have BASIC available as a 
separate program which must be loaded and 
executed. 


When the BASIC interpreter is executed, it first 
checks to see how much memory it has to work 
with and performs other initial operations, after 
which it displays its “Ready” or OK prompt. It is 
then ready for you to load and run your program. 

Interpreted languages are very nice for program 
development, because you can run a program, 
make a change, correction, or addition, and then 
run it again immediately. Since the interpreter re- 
sides in memory along with the program, changes 
to the program are implemented immediately and 
can be tested at once. Also, interpreted languages 
are generally interactive. That is, the user deals with 
the computer on a one-to-one basis; there is no 
waiting for other programmers to take their turn. 

Of course, interpreted languages also have a 
number of disadvantages. In the first place, they 
use memory lavishly. This is because both the inter- 
preter and the user program must reside in mem- 
ory simultaneously, along with the operating 
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system, as shown in Figure 1-1. If the interpreter is 
large and complex, the space remaining for the 
user program is correspondingly small. If the inter- 
preter is smaller, there is more space for user pro- 
grams, but the interpreter cannot handle as many 
special functions as the larger interpreter. This re- 
quires a trade-off that must be decided by the user. 
Fortunately, newer microprocessors and newer ver- 
sions of BASIC can handle larger amounts of mem- 
ory, so the old limitation of 64K of RAM for the 
total system (imposed by 8-bit microprocessors 
with a 16-bit address bus) has been surpassed. 
Nevertheless, interpreted languages do still use 
large amounts of memory. 


USER 
PROGRAM 


INTERPRETER 


OPERAT ING 
SYSTEM 


Figure 1-1. An interpreter must be present in 
memory in order to run the user program. 
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The other main disadvantage of interpreted lan- 
guages is that they operate v-e-r-y s-l-o-w-l-y. A 
program written in machine language will operate 
many times faster than the equivalent program, 
performing exactly the same task, written in 
BASIC. The reason for the slow execution of a 
BASIC (or LOGO, or any other interpreted lan- 
guage) program is that it is not really the user pro- 
gram that is being executed. Instead, it is the 
interpreter that is operating. 

The interpreter scans your program one instruc- 
tion at a time and matches character strings with a 
list of acceptable keywords that it holds. If it cannot 
find a match, it tries to use that character sequence 
as a variable. If it does find a match, the interpreter 
locates the machine language code within itself that 
corresponds to the matched keyword and then ex- 
ecutes that code. This code may need to scan the 
user program for additional data, or it may perform 
other actions. When it is done with one instruction, 
the interpreter scans the user program for the next 
one. If the same line must be executed several 
times, the interpreter must scan it again as if it were 
a new command. 

To speed up the interpreting process, modern 
versions of BASIC perform part of the interpreting 
as you type in the program lines. As you enter 
each line, the interpreter scans it and replaces each 
keyword with a token, which represents that partic- 
ular keyword. Then, when you RUN your pro- 
gram, the interpreter can use the token to find the 
required machine-language code. Mathematical op- 
erators and other special characters are also re- 
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placed with tokens for faster recognition during 
execution of the program. In each case, the token 
is an 8-bit or 16-bit code that is directly recogniz- 
able as such and won’t be mistaken for a normal 
ASCII character. However, these tokens are still not 
really machine language, so the interpretive process 
is still required. 


Sector 2: Compiled Languages 


Compiled languages differ from interpreted lan- 
guages in that the user program is not the program 
actually used by the computer. Instead, as shown 
in Figure 1-2, there is an intermediate step. A sepa- 
rate program called a compiler reads the user pro- 
gram and actually translates it to the equivalent 
machine code. The compiler makes no effort to 
execute either program; it is merely a translator. 
Once the compiler has produced its machine 
code output, it is no longer needed. It has finished 
its job and may be erased from memory. Then, at 
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Figure 1-2. A compiler produces actual machine 
code in accordance with the user program. 


Coding the Program 


any desired time, the machine code produced by 
the compiler may be loaded into the computer and 
executed. Any required external data may be in- 
cluded with the machine program, and different 
data can be included on different runs of the 
program. 

In the early computers, all high-level languages 
used compilers. A programmer would sit in his or 
her office and write a program on a special coding 
form. This form would go to a keypunch operator 
who used a special machine to put the program on 
punched paper cards, one line of program to a 
single card. The resulting deck of cards would then 
go to the computer room where it would be placed 
in line with a number of other programs. Even- 
tually, the program would reach the computer itself, 
and be read, compiled, and executed along with 
whatever data was supplied with it. Results were 
recorded on magnetic tape. 

When the tape was filled up with data, it would 
be removed from the system and replaced with a 
fresh tape. The filled tape was taken to a high- 
speed line printer, and the entire contents of the 
tape was printed out in one session. Finally, the 
original program cards (and possibly the compiled 
program as well) were returned to the programmer 
along with the printed output. 

This procedure was designed to allow the com- 
puter itself to work at top speed as much of the 
time as possible. Computers were very expensive 
and the only way to use them efficiently was to 
keep them working all the time. The fact that it 
took several days for the results to get back to the 
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programmer was considered to be of secondary 
importance. 

With the advent of microprocessors and the per- 
sonal computer, this kind of “batch processing,” as 
it was called, became unnecessary. The central 
processor is no longer so expensive that it must be 
kept running all the time just to be cost effective. 
Nevertheless, compiled programs still have enough 
advantages over interpreted programs that com- 
piler languages are still in common use in many 
applications. 

Compiled programs occupy substantially less 
memory than interpreted programs, and they ex- 
ecute much faster. And it is just as easy to write a 
program in a compiler language as it is to write it in 
an interpreter language. In addition, with the com- 
ing of personal computers and on-line time-sharing 
systems, it is possible to write a compiler language 
program that will permit the user to input data 
while the program is running, and not just when 
the program is sent to the computer room. This is 
equivalent to the INPUT statement in BASIC. 
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Because compiler languages came into existence 
long before interpreter languages, and because 
compiled programs run faster in less memory, there 
are far more compiled languages in existence than 
there are interpreter languages. Typical compiler 
languages include FORTRAN (FORmula TRANs- 
lator), COBOL (COmmon Business Oriented Lan- 
guage), and ALGOL (ALGOrithmic Language). 
FORTRAN and ALGOL are oriented towards 
mathematical procedures and calculations. These 
languages are excellent “number crunchers,” but 
they cannot handle files and verbal data very well. 
On the other hand, COBOL, as its full name sug- 
gests, is oriented towards business-type data proc- 
essing. It can readily handle large files, and it is 
deliberately designed so that its instructions read 
very much like English language statements. How- 
ever, its mathematical capacity is quite limited. 


Sector 3: Newer Languages 


All of the early languages have a common fault: 
they were designed very early in the life of the 
computer. Therefore, they are far from ideal. As 
computers have improved, so have many of the 
concepts that evolved concerning computer pro- 
grams. Newer languages have been developed to 
incorporate these newer programming concepts. 
Structure. One of the primary concepts that ap- 
peared was that all programs should be structured. 
This means merely that the program should retain 
a logical, ordered pattern throughout its execution. 
Each internal routine and subroutine should also 
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have its own order and structure. To be orderly, 
each routine should have a single entry point and a 
single exit point. This should remain true of every 
routine and subroutine in the program. 

The need for structure became apparent when 
corrections and modifications to FORTRAN and 
BASIC programs consisted of adding a new section 
of code to the end of the program and then insert- 
ing a few GOTO statements to execute the code in 
the desired sequence. While this makes the patch- 
ing easy, and the computer really doesn’t care (it 
will do what it’s told in any case), it does make the 
final code difficult to read and follow, and much 
more difficult to patch again. This kind of mixed- 
sequence code is often called “spaghetti code” be- 
cause of its messy, sloppy appearance. Structured 
programming forbids this kind of structure, and in- 
deed generally forbids the use of GOTO at all. 


Coding the Program 


To make structured programming almost auto- 
matic, the compiler language Pascal was devel- 
oped. Pascal recognizes keywords for commands 
and functions much like any other language. How- 
ever, when you write a program in Pascal, you 
must begin by defining each basic procedure in 
terms already known to Pascal. As you define a 
procedure, you give it a name. That name is then 
recognized by Pascal as a working procedure within 
the program. Then you can use that procedure 
name within other procedures. This continues until, 
as the final procedure to be defined, you write the 
outermost shell of the program. Thus, in Pascal, 
you must write the subroutines first, rather than 
last. 

Another structured language, similar to Pascal in 
many ways, is called C. We will explore the opera- 
tion of C later on. 

Combined Languages. As we mentioned ear- 
lier, interpreted languages are easy to use because 
they require no intermediate compilation process. 
However, they occupy a substantial amount of 
memory and are limited in how fast they can run. 
On the other hand, compiled programs run faster 
in less memory, but they must be compiled before 
they can be tested or used. Wouldn’t it be nice if 
we could combine the advantages of compiled and 
interpreted languages, and avoid their disadvan- 
tages? 

Such a language does exist, having been devel- 
oped specifically for fast execution and, at the same 
time, easy modification of the working program. It 
was originally considered to be a “fourth genera- 
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tion” language. However, the computer for which it 
was initially designed would only allow five-letter 
program names. Therefore, this new language was 
called FORTH. 

Like Pascal, FORTH is a structured language. It 
requires that you define all of the internal pro- 
cedures first, in terms already known to FORTH. 
But there the resemblance ends. The FORTH lan- 
guage is also a complete operating system in its 
own right. The program consists of nothing more 
than a dictionary, containing words written in 
FORTH. Each word in the dictionary is in effect a 
command in the FORTH language. To execute the 
command, you need only type the word on the 
keyboard. In this mode, FORTH compares the 
word you typed on the keyboard with each word 
in its dictionary. When it finds a match, FORTH 
executes the matching word. If you type in a 
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sequence of words, placing spaces between them, 
FORTH will execute them all in turn. This is the 
interpretive mode of FORTH. 

However, FORTH is not limited simply to word 
interpretation. At any time, you can define a new 
word for the dictionary. When you do this, FORTH 
still interprets your input character string, but this 
time it compiles the words you specify into the 
dictionary as a brand new word. Once compiled, 
there is no difference between the new word and 
any other word in the dictionary. Furthermore, if 
you wish to change the word for some reason, you 
can tell FORTH to FORGET the original definition 
before you type in the new definition. 

Besides combining the advantages of interpreter 
and compiler into one neat package, FORTH ex- 
ecutes much faster than any other interpreter and 
even faster than many compiled programs in other 
languages. In fact, FORTH normally executes at 
about half the speed of programs actually written in 
machine language, and occupies the same, or even 
a little less, memory space. 

Specialized Languages. Languages such as 
FORTRAN and COBOL are oriented toward spe- 
cific types of operations. But there are a number of 
occasions when an even more specialized language 
is useful. These include the “CALC” programs, 
which turn your computer into an electronic 
spreadsheet for mathematical analysis and forecast- 
ing, and database management programs which al- 
low statistical analysis and handling of large files or 
lists of data. Programs of this type are effectively 
very limited languages that permit fast handling of 
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the data and will, if required, produce a printed 
output showing the results of the search or analysis. 
However, these languages are so specialized that 
we will not cover them here. 

In this Learning Guide, we will give program ex- 
amples in BASIC, FORTRAN, COBOL, Pascal, C, 
and FORTH. This will show some of the variety in 
instruction syntax and specific command names. 
But the same general rules for coding apply equally 
to other languages. Once you know the names of 
the available commands and the required syntac- 
tical format (which you can get from any of the 
large variety of books available in many book- 
stores) in a particular language, you will find that 
you can apply the same coding techniques and 
methods, changing only the arrangement of each 
command structure or procedure, and the program 
will run equally well in the new language. 

Now, let’s move on to the specific types of com- 
mands available in different languages, and see 
how they appear in different languages. 
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THE PRIMARY CLASSES OF COMPUTER 


COMMANDS 


Computer commands or instructions may be de- 
scribed in a number of different ways, according to 
the current requirements. For learning a language, 
and for using it to code a program, one of the most 
useful approaches is to classify the available in- 
structions in terms of their functions. For example, 
some instructions are for general processing and 
computation. Others tell the computer to perform 
input and output operations, while still others are 
intended to control the flow of the program in vari- 
ous ways. With these classifications in mind, let's 
take a look at the various types of commands and 
functions available in a number of different lan- 
guages. 

If your computer is available now, turn it on and 
insert your Program Disk in Drive 8 if necessary. 
Then, type in the commands: 


LOAD “TRACK2’ <return > 
RUN < return > 


Return to this point when your computer instructs 
you to do so. 
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Sector 1: General Processing Commands. 


The first and most important of the general pro- 
cessing commands is the variable assignment 
statement. This is the statement that defines a 
memory variable and assigns a value to it. In most 
languages, this is accomplished by stating the vari- 
able name, an equal sign (=), and then the value 
or expression to be evaluated, whose final value 
will be assigned to that variable in memory. In 
BASIC, this is done by means of one of the follow- 
ing commands: 


<variable name> = <éxpression> 
or 
LET <variable name> = <expression> 
The keyword LET explicitly states that a value 


defined by the <expression> is to be assigned to 
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the variable <variable name>. In the absence of 
the LET command, BASIC will try to use the 
<variable name> as a command keyword. If this 
fails, BASIC will assume that it is a variable name 
and will proceed to evaluate the <expression>. 
This is known as an implied LET. 

In most languages, the assignment statement is 
the same as the implied LET, with possible minor 
variations. For example, in Pascal the statement 
would be: 


<variable name>: = <expression>; 


The exception to this kind of assignment state- 
ment is FORTH. The FORTH language uses a last- 
in, first-out parameter stack where all numbers are 
stored in the order in which they are entered or 
calculated. Furthermore, FORTH uses a mathe- 
matical notation known as Reverse Polish Notation, 
or RPN. This is the sort of math used by the pocket 
calculators made by Hewlett-Packard (the HP-35, 
HP-45, etc.). Also, in FORTH a named variable 
becomes a word in the dictionary. Therefore, the 
initial definition of the variable must create the ap- 
propriate word in the dictionary, and takes this 
form: 


<expression> VARIABLE <variable name> 
The word VARIABLE in FORTH defines a new 


word in the dictionary to act as a variable. The 
<expression> is evaluated and may, if desired, be 
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a simple number. This value becomes the initial 
value for <variable name>. 

In some versions of FORTH, no initial value is 
assigned to a variable when it is defined. In these 
cases, <expression> is left out above. Then, for 
these cases and for all cases where the value of the 
variable must be changed, the instruction sequence 
is: 


<expression> <variable name> ! 


The FORTH word ! (pronounced ‘store’) tells 
FORTH to store the value of the <expression> 
into the space previously allocated for <variable 
name>. 

General processing commands include all math- 
ematical operations and any logical operations that 
may be permitted. In most languages, the primary 
mathematical operations of addition (+), subtrac- 
tion (—), multiplication (*), and division (/) are per- 
mitted. Usually, exponentiation (raising a number 
to a power), is also permitted. This operation is 
symbolized by “**” in FORTRAN, and by “ #” or 
“-” in BASIC. Other languages use one or the 
other of these symbols. 

Logical operations such as AND, OR, NOT, and 
XOR are also part of general processing. Each of 
these symbols causes a specifically defined opera- 
tion to be performed between two numbers, with 
the result retained for future use. Mathematical ex- 
pressions form the basis of all general processing 
operations within a program. By putting these to- 
gether with the assignment statements described 
above, we have the means of performing a wide 
range of calculations, even going beyond the basic 
math and logical operations actually defined for the 
language. 
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Many mathematical calculations are required so 
often that most languages incorporate them as spe- 
cial functions. These include such functions as SQR 
(SQuare Root), LOG (natural or Naperian LOG- 
arithms), EXP (natural antilog, or e raised to a 
power), and the trigonometric functions SIN, COS, 
TAN, and ATAN (ArcTANgent). The main require- 
ment with trigonometric functions is to remember 
that they deal with angles in radians, rather than in 
degrees. Similarly, the logarithmic functions (LOG 
and EXP) deal with natural logarithms, rather than 
with decimal logarithms. 

Character strings can also be manipulated in 
most languages, and it is often necessary to isolate 
a specific substring within a character string for 
various testing procedures or for further manipula- 
tion. Functions such as LEFT$, RIGHT$, and 
MID$ accomplish this task easily. It is also possible 
to concatenate (or link together) strings with the 
“+” operator. This does not mean adding the 
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ASCII values of string characters the way you 
would add numbers, though. Rather, the ex- 
pression: 


A$ + B$ 


represents a string whose length is the same as the 
sum of the lengths of A$ and B$. The left end of 
the string is the same as A$, and the right end is 
the same as B$. By the same token, you cannot 
use “—” to subtract one string from another. 
Rather, you must use LEFT$, RIGHT$, and MID$ 
as needed to define those portions of a string that 
you wish to keep, and redefine the string accord- 
ingly. In some versions of a number of languages, a 
function similar to BASIC’s INSTR is provided to 
locate the occurrence of a substring within a larger 
string. 

In BASIC, there are also a number of functions 
that convert data back and forth between string 
form and numeric form. For example, CHR$ forms 
a 1-character string from its assigned ASCII value. 
ASC performs exactly the reverse operation: it re- 
turns the ASCII value of a string character. For con- 
verting an entire number to string form, the STR$ 
function is used. To convert a numeric string to a 
real number, the VAL function is provided. Other 
languages may have some, all, or none of these 
functions, possibly using different function names. 


Sector 2: Input/Output Commands 


All of the processing in the world is useless unless 
the original data can be entered into the computer 
and the final results can be obtained from the com- 
puter. This is the purpose of input and output (I/O) 
instructions. 
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I/O commands fall into three basic catagories: 
I/O to the user terminal, reading constant data, and 
I/O to files in mass storage (usually disk or mag- 
netic tape). Batch processing systems do not in- 
clude I/O to the user terminal, but they do have the 
other two types. Any on-line user system, where 
the user is in direct communication with the com- 
puter, will probably have all three types of I/O com- 
mands. 

Terminal I/O involves the INPUT (from the key- 
board) and PRINT (to the screen) commands. 
These are the commands that display information 
on the screen while the program is running and 
accept user input to the program currently being 
executed. This data is then processed by the pro- 
gram in accordance with its instructions. 

In BASIC, reading constant data involves such 
staiements as READ, DATA, and RESTORE. This 
technique is used in many languages (although 
possibly with different command keywords) to in- 
corporate a large amount of constant (or seldom- 
changed) data without having to explicitly define 
variables to hold the data ahead of time. 

I/O to mass storage involves files. This usually 
means disk files on personal computers, or mag- 
netic tape files on older mainframes (cassette files 
for low-end personal systems). Computer programs 
are normally stored as files in mass storage (at least 
after they have been coded). This uses the com- 
mands LOAD and SAVE. In addition, programs 
can create, read, modify, and rewrite data files to 
mass storage, using such commands as OPEN, 
CLOSE, GET, PUT, etc. The exact format and key- 
words for these commands will vary from language 
to language. 
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Sector 3: Program Control Commands 


While it is possible to write most programs in 
straight-line fashion, with no breaks or changes in 
sequence, this is not the best way to design most 
programs. Very often a series of instructions must 
be repeated a known (or unknown) number of 
times. In other cases, a given instruction sequence 
must be used at many different places within a 
program. In many programs, decisions must be 
made based on the present value of some variable 
or calculation. Then the program must select be- 
tween two or more courses of action, according to 
the result of its evaluation. 

There are three basic program structures de- 
signed to permit such control actions. These are the 
loop, to repeat a sequence of instructions a desired 
number of times; the subroutine, to permit the 
same instructions to be used from many points 
within a program; and the decision statement, to 
make comparisons or test for limits and jump to the 
appropriate point in a program according to the 
result of the test or comparison. 

In BASIC, loops are defined with the statements 
FOR and NEXT. In FORTRAN, the equivalent 
statements are DO and CONTINUE. FORTH uses 
DO and LOOP for this purpose, while other lan- 
guages use other terms. It is also possible to define 
an indefinite loop, where the number of repetitions 
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is not initially known, or the loop must be repeated 
until a particular condition has been met. This kind 
of structure may take on such forms as BEGIN. . . 
UNTIL, WHILE... DO... ENDDO, BEGIN... 
WHILE ... REPEAT, or something similar, de- 
pending on the specific language and its structure. 

Subroutines might be called with statements 
such as GOSUB in BASIC, or CALL in FORTRAN. 
FORTH does not use subroutines at all; instead, 
each FORTH word is already a subroutine in effect, 
and is called simply by using its name. Pascal is 
similar, in that each routine or subroutine is defined 
as a procedure which may then be invoked by 
using its name. 

Decisions are made with IF statements in most 
languages, although the exact structure of the IF 
statement will vary according to the language. IF 
statements may be used in all languages to select 
which of two sequences of instructions to execute, 
without executing the other sequence, or to deter- 
mine whether or not to execute certain instructions. 


Sector 4: Sorting out the Instruction Set 


With the many languages to choose from, and the 
different commands available in a given language, 
how can we sort through a given instruction set or 
manual to find the specific instruction we will need 
in a particular program line? What is the required 
syntax for that instruction? Exactly what does it ac- 
complish? 

Of course, after you have worked with a lan- 
guage for a while you will find that you have mem- 
orized most of the instructions and the rules for 
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using them. But what if you are using several differ- 
ent languages for different programs or purposes? 
What if you are just learning a language? It’s hard 
to find the exact information you need in that 394- 
page manual when you aren’t even sure what key- 
word you are trying to find! 

The answer is to make up a list of the instruc- 
tions and functions available in that language. In 
fact, many language packages come with a “pocket 
reference card” that lists the available commands in 
that language and indicates the proper syntax for 
them. If you have such a card, be sure to have it 
handy. If not, draw one up. 

The most practical arrangement of keywords for 
such a list is alphabetically by classification, with 
commands separated from functions. That is, list all 
of the commands for processing alphabetically, fol- 
lowed by the processing functions. Then list the I/O 
commands and the I/O functions, followed by the 
control commands and functions. 

With each command and each function, specify 
the allowable syntax structure(s) that the language 
will expect, and state briefly the purpose of the 
instruction. Don’t try to define the instruction in 
detail; that is what the manual is for. But by listing 
the instructions in this fashion, you can rapidly lo- 
cate the instruction you need to perform a particu- 
lar task within the program. Then, if you need 
additional detail, you can quickly locate that in- 
struction in the manual. Listing the allowed com- 
mands and their required syntax in this fashion can 
save a lot of time and frustration when you code 
the program. 
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TYPICAL PROGRAM CONTROL 
STRUCTURES 


=} 


Both processing commands and I/O commands 
are fairly straightforward in any language. Of 
course, as the programmer you must be careful of 
the order in which a series of instructions will be 
executed, but at least each instruction represents a 
specific action which is completely defined by the 
instruction. This is not true of many control struc- 
tures in a program. 

Control structures within a program are used to 
change the sequence in which instructions will be 
executed. Such a change may be unconditional, or 
may be determined by a test of some sort (as with 
an IF statement), or else be a requirement that a 
series of instructions be executed more than once 
(a program loop). Subroutines are also made possi- 


ble by the use of control structures. 
If your computer is available now, turn it on and 


insert your Program Disk in Drive 8 if necessary. 
Then type in the commands: 


LOAD ’TRACK3"(return) 
RUWN(return) 
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Return to this point when your computer in- 
structs you to do so. 

Of course, the exact control structures used in a 
program will be dictated by the requirements of the 
language in which the program is coded. Nev- 
ertheless, there are a number of similarities dictated 
by the requirements of the control structure itself. 


Sector 1: Conditional Program Execution 


There are many situations within programs where a 
sequence of instructions must be executed if and 
only if a particular condition is met. Or, one of two 
or more groups of instructions must be executed 
depending on the present status of some piece of 
data within the program. If we only want to decide 
whether or not to execute a given sequence of in- 
structions, or which of two sequences to execute, 
we have an IF statement. If we must decide among 
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three or more possible sequences of instructions, 
the result is known as a “case” statement. 

In its simplest form, the IF statement in BASIC 
takes the form: 


IF <test> THEN <action> 


In this case, the <test> is a comparison between 
two values or expressions. If the result of the test is 
true, the <action> will be performed. If the 
<test> yields a false result, the <action> will be 
ignored. In BASIC, the <action> may be a pro- 
gram line number or a series of commands. 

In Pascal, line numbers are not used. Therefore, 
the IF statement must take a different form. Stand- 
ard usage is: 


IF <test> 
<command> 
<command> 
<command> 


ENDIF 


Any number of commands may be placed between 
IF and ENDIF, including another IF statement if 
desired. However, if another IF structure is placed 
inside this one, both the IF and ENDIF statements 
must appear inside the outer IF structure. Overlap- 
ping is forbidden, and is impossible anyway (Think 
about it). 
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The language C uses a similar structure, but 
without the ENDIF keyword. Instead, the <test> is 
enclosed in parentheses () and the <action> to be 
taken is enclosed in braces {}. The result may be 
placed on multiple lines if desired, and looks like 
this: 


IF (<test>) {<action>} 


FORTRAN also does not use an ENDIF indicator. 
Instead, the IF statement takes on the form: 


IF (<test>) #1,#2,#3 


With this structure, the <test> is a mathematical 
expression (not a comparison). The three # sym- 
bols are statement numbers (not all statements in 
FORTRAN need to be numbered, but numbers are 
required for any statement that will be referenced). 
If the <test> expression evaluates to a negative 
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number, control goes to statement #1. If <test> 
= 0, statement #2 will be executed next. If <test> 
is positive and non-zero, statement #3 will receive 
control. These statements may be anywhere in the 
program, and the statement numbers need not be 
in any particular numeric sequence. Some versions 
of FORTRAN allow variations in this structure for 
special cases. 

COBOL is similar to BASIC, except that the 
comparison is stated in words rather than symbols: 


IF <expression> IS GREATER THAN 
<expression> PERFORM <action> 


The different language is FORTH. All FORTH 
commands operate on data already present on the 
parameter stack. Therefore, the IF statement in 
FORTH takes the form: 


<test> IF <action> THEN 


The <test> leaves a flag on the stack which will 
either be false (0) or true (non-zero). A false flag 
will cause <action> to be bypassed. ENDIF is 
often provided as a synonym for THEN. 

It is quite possible with most languages to indi- 
cate an alternate sequence of instructions, in case 
the <test> fails. This is inserted as an ELSE clause 
within the IF statement. In BASIC, this takes the 
form: 


IF <test> THEN <true action> ELSE <false 
action> 
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In this type of structure, either <true action> or 
<false action> will be performed, depending on 
the result of the <test>. 

Other languages that permit an ELSE clause are 
similar, as shown in Figure 3-1. FORTRAN does 


Figure 3-1. |F ... THEN... ELSE structures for 
different languages. 
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not include ELSE, since its IF structure inherently 
specifies a three-way choice. It is not necessary in 
FORTRAN that the three statement numbers be 
different. 

For more than one or two choices, we need 
something more extensive than an IF. . . THEN or 
IF ... THEN... ELSE statement. The extended 
choice statement is known as a case statement. 

In BASIC the case statement is implemented in 
the form: 


ON <expression> GOTO #1,#2,#3,#4,45..... 


Here, <expression> is a numeric variable or ex- 
pression that evaluates to a positive integer. The 
appropriate line number (#1, #2, #3, etc.) will be 
executed next, according to its position in the list 
and the value of <expression>. It is not possible to 
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pick a line number directly according to an irregular 
series of values or characters. 
In Pascal, a CASE statement takes the form: 


CASE <variable name> OF 


<choice #1> : <action>; 
<choice #2> : <action>; 
<choice #3> : <action>; 
<choice #4> : <action>; 
<choice #5> : <action>; 
<choice #6> : <action>; 
<choice #7> : <action>; 


END; 
A case structure in C looks similar: 


SWITCH ( <expression> ) 


CASE <labell> : <statementl> 
CASE <label2> : <statement2> 


DEFAULT 
i 


: <statement> 


Some versions of FORTH incorporate a CASE 
structure. If a particular version of FORTH does not 


MODULE 4 


Coding the Program 


Track 3 


include CASE words, they may easily be added to 
the dictionary at any time. The exact format of a 
case statement will depend on the way the CASE 
words are defined and will be included in the docu- 
mentation for that particular version of FORTH. 

Most other languages implement a case structure 
with a sequence of IF statements in the form: 


Pe. 20 HEN... ~ELSEAF «a. THEN : ELSE 
[Pc oT EEN ge... 


This kind of structure can become rather clumsy, 
but it does get the job done. 


Sector 2: Definite Loops 


A common requirement in many programs is to 
repeat a series of instructions some number of 
times to accomplish a task. In such a case, we can 
establish a program loop. If we know ahead of time 
how many times the sequence must be repeated, 
we can establish a definite loop, where the loop 
limits are defined as part of the initial loop param- 
eters. 
In BASIC, the definite loop takes the form: 


FOR <var. name> = <start value> TO <end 
value> STEP <step size> 

<sequence of instructions to be repeated> 
NEXT <var. name> 


In this structure, the <step size> may be any real 
number, positive or negative. If the STEP keyword 
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is omitted, <step size> defaults to +1. The se- 
quence of instructions may be any valid instruc- 
tions, including another FOR ... NEXT loop if 
desired. The only restriction in such a case is that 
the inner loop be completely contained within the 
outer loop. Loops may not overlap. 

FORTRAN uses a similar structure for definite 
loops: 


DO <line #>,<var. name> = 
<start>,<end>,<step> 

<sequence of instructions> 
<line #> CONTINUE 


The CONTINUE statement is really just a 
“dummy” command that terminates the loop. You 
can identify the last line of the instruction sequence 
with <line #> instead, so long as that statement is 
not part of an IF structure. 

COBOL does not include this type of program 
loop. However, Pascal does, and it looks like this: 


FOR <index> := <start> TO <end> DO 
<instruction>: 


Pascal does not use a NEXT statement, and only 
the line following the FOR line will be repeated. To 
repeat a group of instructions, either predefine 
them as a procedure, or else surround them with 
the BEGIN and END control words. 

C is similar to Pascal, and uses the format: 


FOR (<index> = <start>; <index> <= 
<end>; <index>+) 
<instruction> 


As with Pascal, only the instruction following the 
FOR line will be repeated. However, multiple 
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statements can be placed in the loop, if they are 
surrounded by braces { } to identify them. 

As usual, FORTH is the different one. This lan- 
guage has two forms of definite loop, according to 
whether or not the step size is +1: 


<end> <start> DO <instruction sequence> 
LOOP 


or 


<end> <start> DO <instruction sequence> 
<step size> + LOOP 


Sector 3: Indefinite Loops 


There are many cases where a loop must be re- 
peated an unknown number of times. This occurs 
when the program is waiting either for a condition 
to be met or for an external activity to occur. 
Sometimes the condition is met as a result of re- 
peated computations, and sometimes as a random 
event, either internal or external to the program. In 
any case, a loop which will end when the event 
occurs is known as an indefinite loop. 

Indefinite loops may be set up in a number of 
ways. In BASIC, we might use an IF statement 
which will return control to the top of the loop if the 
event has not yet occurred, or the condition has not 
been met. FORTRAN and COBOL also have no 
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such structure. However, most other languages 
have keywords that will define the desired loop 
structure directly. 

The Pascal indefinite loop takes the form: 


WHILE <condition> DO 
<statement> 


As with the FOR statement, only one <statement> 
will be repeated, unless it is a BEGIN keyword de- 
noting a block of statements. Here, the 
<statement> will be executed repeatedly WHILE 
the <condition> is true. As soon as the <condi- 
tion> becomes false, the program will continue 
with the next instruction. 

A second form of indefinite loop in Pascal takes 
the form: 


REPEAT 
<series of statements> 
UNTIL <condition> 


The difference between these formats is that the 


first one tests the <condition> first, and, if the 
<condition> is false, will not execute the 
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<statement> at all. The second format executes 
the <statements> first, and then tests the 
<condition>. Thus, the second format will always 
execute the <statement> at least once. This is 
often a crucial distinction, depending on the re- 
quirements of the program. 

Indefinite loops in C take a similar form to those 
in Pascal: 


WHILE <condition> 
<statement> 


or: 


DO 
<statement> 


WHILE <condition> 
FORTH has the same basic structures: 


BEGIN <condition> WHILE <statements> 
REPEAT 


or: 

BEGIN <statements> <condition> UNTIL 
FORTH often allows the use of END as a synonym 
for UNTIL. In addition, FORTH allows the forma- 


tion of a “forever” loop in the form: 


BEGIN <statements> AGAIN 
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This structure might be used in an applications pro- 
gram where the programmer does not want the 
user to be able to exit the application except by 
turning off the computer. 


Sector 4: Subroutines and 
Macroinstructions 


Program loops (either definite or indefinite loops) 
are designed to execute a series of instructions a 
desired number of times. In a few cases, the in- 
structions will be executed only once or even skip- 
ped completely, but normally the sequence will be 
repeated some number of times. 

Often a series of instructions must be executed 
two or more times, but not all at once. Instead, the 
sequence might be required once at each of two or 
more places within the program. The same se- 
quence of instructions must be executed each time, 
but the intervening instructions are different. 
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If the instructions to be repeated are few in 
number or very simple, we can simply code a new 
set of instructions into the program each time they 
are required. For example, the instruction se- 
quence: 


A=A+1 
B= B= 3 *A) 


might be required at many different places in a 
program. This series is so simple that we might just 
as well type it in wherever it is required. 

If we need a short instruction sequence of this 
type often, some languages permit us to define a 
new instruction, called a macroinstruction or simply 
macro. Then, when the program is compiled, the 
compiler routine substitutes the actual instruction 
sequence whenever the macro is encountered in 
the user’s program. The instructions will still be re- 
peated throughout the program, but the coding 
process has been simplified. 

However, if an instruction sequence is long or 
complicated, we don’t want to code multiple copies 
of it in line with the program flow. In such a case, 
we can define the sequence once, and then call the 
same sequence of instructions whenever it is 
needed. The sequence of instructions is now de- 
fined as a subroutine. 

A subroutine is always distinguished by the fact 
that the last instruction executed within the routine 
is always a RETURN instruction (or some equiv- 
alent keyword). As you learned in an earlier mod- 
ule, BASIC programs use the command: 
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GOSUB <line #> 


to transfer control to a subroutine beginning at 
<line #>. The subroutine executes until a RE- 
TURN statement is encountered, at which point 
control returns to the instruction immediately fol- 
lowing the GOSUB statement. The subroutine is 
part of the BASIC program and has its own unique 
series of line numbers within that program. 

In FORTRAN, where not all lines need to be 
numbered, a subroutine must be defined before it 
is called. As part of the definition, space must be 
allocated for each variable that will be used to pass 
information back and forth between the subroutine 
and the main program. The main program must 
also specify an equivalent list of variables. Such 
variables become global variables, which will exist 
for different routines. Then, the subroutine may be 
defined as follows: 


SUBROUTINE <name> (<global variable list>) 
<instructions> 


RETURN 


Then, the main program can call the subroutine 
with the instruction: 


CALL <name> 


The <name> must match exactly, so that the com- 
piler can locate and identify the correct subroutine. 
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However, the global variable list, which must be 
specified at the beginning of the main program and 
each subroutine, need not use the same variable 
names in each position; they need only be of the 
same type (real or integer) in the same sequence. 

In Pascal and FORTH, subroutines are not al- 
lowed or used. Instead, a given procedure (or 
FORTH word) is fully defined before it is used. 
Then it can be called at any future time just by 
including its name in any later Pascal procedure or 
FORTH word. COBOL also is not structured to use 
subroutines as such. C is very similar to Pascal in 
this respect; you can define “structures” and then 
reference them later on, but there is no specific 
subroutine call used. 

Now, let’s take a closer look at the requirements 
for coding different kinds of instructions. 
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CONVERTING FLOWCHARTS TO CODE 


A fully detailed flowchart, Chapin diagram, or 
other graphic representation of a program should 
translate to high-level source code (the computer 
program actually written by the programmer) on a 
consistent one-to-one basis. That is, each step in 
the fully detailed diagram should correspond to a 
single command in the language you are using to 
code the program. Control structures, such as we 
examined earlier, may not be converted on this 
basis, but processing and I/O commands should at 
least come close. 

Of course, some details will not appear on the 
chart. For example, if you plan to open and field a 
random-access file, the chart will simply state that. 
It will not normally specify the exact length of each 
field within a record, because that detail may be 
adjusted even within the final program, to accom- 
modate the data to be placed in the file. But you 
should have the intended field lengths and names 


MODULE 4 


listed separately, so that you will not have to design 
them all over again when you code the program. 
The coding phase should be as mechanical as 
possible. 

To see the correlation between a step in the chart 
and an instruction in the program, we will look at 
several examples of processing and I/O operations 
in a number of different languages. In the next 
track, we will combine these with various control 
structures to form practical routines for use in a 
variety of programs. 

We do not have a demonstration program on 
disk for this track. Instead, you are invited and en- 
couraged to try the various instruction sequences 
that we will list, in whatever languages you may 
have available for your particular computer. Our 
demonstration programs are limited to BASIC, be- 
cause we cannot be sure that any other language 
will be available to you at this time. 
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Sector 1: General Arithmetic Operations. 
Any arithmetic operation is generally charted in al- 
gebraic notation and translates directly to source 


code in most languages. For example, for the 
flowchart step: 


SUM =A+B+C 


we can immediately write in either BASIC or FOR- 
TRAN: 


SUM=A+B+C 
In C we would add a semicolon at the end: 
SUM =A+B+4+C; 


while in Pascal we would also change the assign- 
ment slightly: 


SUM:=A+B+4+C; 


Cobol was not primarily designed for arithmetic op- 
erations, so its version is a bit more complex: 


COMPUTE SUM = A+B+C 


The FORTH version uses reverse Polish notation 
and its own built-in store word: 
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AB + C+ Sut 


where the ! word (pronounced “store”) stores the 
final sum into the predefined variable named SUM. 
The values A, B, and C must be predefined con- 
stants. If A, B, and C are to be variables, we must 
change the line to: 


A @B@ + C @;+ SUM ! 


where @ (pronounced “fetch”) is required to get 
the contents of the variable (naming the variable 
provides its location, not its value). 

Now, suppose that we want to find the average 
of the three numbers A, B, and C. We already have 
their sum, so the next step in the flowchart might 
be: 


AVERAGE = SUM /3 
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In each language the calculation will take the same 
format as the calculation for SUM. The only dif- 
ference in most cases will be that the expression 
SUM /3 will replace A + B + C, and AVERAGE will 
replace SUM. In FORTH, the command becomes: 


SUM @ 3 / AVERAGE ! 


which again has the same format as the computa- 
tion of the SUM. 

All of these languages (and most other computer 
languages) use the four symbols (+, —, *, /) to 
denote addition, subtraction, multiplication, and di- 
vision. In addition, all of them except for FORTH 
will inherently perform all multiplication and divi- 
sion operations before performing addition and 
subtraction, in accordance with the standard rules 
for performing arithmetic. Parentheses may be 
used as necessary to modify the order of prece- 
dence, again in accordance with the standard rules. 

FORTH does not use parentheses, nor is it con- 
cerned with precedence. Instead, FORTH will per- 
form each operation in order, as it appears on the 
command line. All required operands must already 
be present on the parameter stack. Thus, you se- 
lect your own order of precedence by choosing the 
order in which operations are specified. 

Most languages can readily handle quite com- 
plex mathematical expressions. For example, con- 
sider the calculation for the monthly payment in 
the LOAN program from Module 1: 
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Regular Payment = ———-+*___ 
i -NY 
1- (y+) 


In the BASIC program, this formula became: 


PM = (MR « LO)/(1 - (MR+1) 4 (-NP)) 


Even here, some precalculation had been per- 
formed; ratio i/N had already been calculated as 
MR, and the product NY had already been provided 
as NP. This expression is by no means the limit of 
complexity allowed. However, it is well to avoid 
more complex expressions if possible. The reason 
for this is that it is too easy to overlook a closing 
parenthesis, or to put operands in the wrong order. 
The more complex an expression becomes, the 
easier it is to make a mistake, and the harder it is to 
find it later on. 
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Sector 2: Mathematical Functions 


Mathematical functions may be used in place of 
any individual value in an expression. Most lan- 
guages include a number of functions to perform 
commonly-required operations. Suppose your 
flowchart or diagram included a step: 


RAD = VB? — 4AC 


This expression forms a part of the quadratic for- 
mula, which may be used to find the roots of a 
quadratic equation. The expression within the 
square root symbol can be written as: 


B42 — 4*A*C 


Now, how can we specify the square root of this 
value? 

In BASIC, we can use the built-in square root 
function, SQR. The resulting expression looks like 
this: 


RAD = SQR(B42 — 4*A*C) 


In this expression, the SQR is the name of the 
function in BASIC. The function name is always 
followed by a pair of parentheses. The expression 
within the parentheses is called the argument of the 
function. That is, this is the expression to which, 
after it is evaluated, the function will be applied. 
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Thus, upon seeing this instruction, BASIC will first 
evaluate the expression inside the parentheses in 
accordance with the rules of precedence, and it will 
then take the square root of the resulting number. 
The resulting square root will be stored as the vari- 
able RAD. 

Most languages include a square root function, 
but not always by the name SQR. For example, in 
FORTRAN it is SQRT or even SQRTF (the F indi- 
cates a function). In Pascal, it is also SQRT (SQR 
exists, but it forms the square, rather than the 
square root). The basic FORTH language works 
with integers only, either 16 or 32 bits long. There- 
fore, it does not include any functions of this type. 
But it is possible to add words to FORTH to handle 
floating point (real) numbers. Then it is meaningful 
to add function words as well. The C language 
includes functions, but for different purposes and in 
a different way. Roots, logarithmic and trig- 
onometric functions, and other such functions must 
be defined within the program; no function library 
is provided. 

Regardless of the function required, the function 
name is always accompanied by the appropriate 
argument in parentheses (or some equivalent). 
When the function has been calculated, the result is 
a number which may be used in any desired fur- 
ther calculations. 

The exact library of functions available will de- 
pend on the language you are using, and the exact 
dialect or version of that language. Thus, if you are 
planning to make extensive use of functions, make 
every effort to use a language that includes those 
functions you wish to use. For example, if you are 
using trigonometry or logarithms, you might use 
BASIC, FORTRAN, or Pascal, since they have 
these functions built in. You can do the same job in 
C or FORTH, but you will have to design the 
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routines to perform the necessary functions, as part 
of your program. 

Regardless of the mathematical operation or 
function, processes translate directly and easily 
from flowchart or other diagram to program code. 
You will probably have to adjust the program 
source code syntax slightly, but the relationship be- 
tween the diagram and the program is still very 
close. If the mathematical expression on the dia- 
gram is very complex, you may wish to break it 
down into a number of smaller steps, with known 
intermediate results. But there will still be a close 
correlation between the two. In fact, if the ex- 
pression is too complex to code directly, you 
should break it down on the chart before you code 
it, so that you will not be trying to do two things at 
once during the coding process. 


Sector 3: String Operations and Functions 


In those languages that include string handling ca- 
pability and string functions, the correlation 
between the diagram and the program code is just 
about as close as for mathematical operations and 
functions. Of course, the major language with 
string-handling capability is BASIC. But Pascal also 
allows string operations, and it has a number of 
built-in string functions of its own. In C and 
FORTH, strings are not incorporated. However, it is 
possible to define structures and routines to handle 
them. FORTRAN is not designed to handle string 
variables or functions to any extent. Accordingly, 
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for string examples, we will look only at BASIC and 
Pascal. 

Suppose we are presented with a list of character 
strings of varying lengths. However, for visual out- 
put we want only the first eight characters of any 
string. On the other hand, if a string contains less 
than eight characters, we want to add spaces to fill 
it out. Of course, there are several ways to accom- 
plish this. The flowchart box might look like this: 


Use first 8 characters of NAME$ 


Pad with spaces to 8 characters” 


In BASIC, we might first use LEFT$ to limit 
NAMES$ to 8 characters, and then use an IF state- 
ment to decide whether or not to add trailing 
spaces. However, an easier way is to write the 
LEFT$ function this way: 


SNAME$ = LEFT$(NAME$ +“ ” 8) 
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This function places 8 trailing spaces after NAME$ 
regardless of the length of NAME$. Then, when we 
take the leftmost 8 characters, we will automatically 
get however many spaces we need, all in one in- 
struction. 

In Pascal, we can still do it in one instruction, 
although it requires a combination of two functions: 
SNAME := COPY(CONCAT(NAME,’ *), 1,8) 

Additional string processing is permitted in both 
of these languages, although the actual instructions 
available are different for each language. Nev- 
ertheless, there should still be a very close rela- 
tionship between the flowchart or diagram and the 
program code for all processing operations. 


Sector 4: Defining Fixed Data 


Processing operations by themselves are direct and 
straightforward, which is why they can be explicitly 
defined on a flowchart and then rewritten directly 
in program code. Input and output operations can 
become a bit more complex, so it is often neces- 
sary to write more program code than the diagram 
would seem to indicate. This requirement is seen 
primarily when working with data files, where the 
details of file handling go beyond the working logic 
of the program itself. 

In BASIC, it is quite possible to place large 
amounts of constant data into a program using 
DATA statements. The DATA statements themselves 
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will not show up in the flowchart or Chapin dia- 
gram. Only the requirement to READ the data will 
be diagrammed. 

For example, suppose we are designing a pro- 
gram to match items in a store inventory with item 
names and prices on a master inventory list. The 
store’s inventory might be kept in a data file, but 
the master inventory list would be contained in the 
program, since it would seldom or never be 
changed. In such a case, the program loop to read 
the data from the program itself would include the 


box: 
Read item name, price 


The BASIC command line that corresponds to this 
is: 


READ NAME$,PRICE 


But if you simply incorporate this line in your pro- 
gram, you will get an “Out of Data” error message. 
You must also place, at some point in the program, 
a series of commands of the form: 


DATA “<name of item #1>”,<price of item#1> 
DATA “<name of item #2>”,<price of item#2> 
DATA “<name of item #3>”,<price of item#3> 
DATA “<name of item #4>”,<price of item#4> 
DATA “<name of item #5>”,<price of item#5> 
DATA “<name of item #6>”,<price of item#6> 
DATA “<name of item #7>”,<price of item#7> 
DATA “<name of item #8>”,<price of item#8> 
DATA “<name ofitem #9>”,<price of item#9> 


Any number of data items may be incorporated 
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into the program this way, and it is permissible to 
place two or more data items in a single DATA 
statement, or even to use two DATA statements, 
one for the name of an item and another for its 
price. The only requirement is that the data ele- 
ments be listed in DATA statements in the exact 
order that BASIC will be required to read them. If 
this requirement is not met, you will get another 
error message as soon as BASIC tries to read a 
string value into a numeric variable name. 
FORTRAN is not designed to manipulate char- 
acter strings or work with files, so it is not really 
suited to this sort of application. But it can accept 
numeric data in this fashion, using the batch proc- 
essing mode. In this case, the data must be placed 
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at the end of the program, and a special FORMAT 
statement is placed in the program to tell FOR- 
TRAN exactly how the data is organized. Then the 
FORTRAN READ statement takes this form: 


READ (<line #>,<device #>) <variable list> 


The <device #> tells FORTRAN where the infor- 
mation is to be found (tape unit, disk, punched 
card reader, etc.) and the <line #> references the 
FORMAT statement. This statement may be any- 
where in the program, but it must appear some- 
where. It consists of a series of field definitions in 
the form: 


<line #> FORMAT (<count><type> <width>, 
<count><type><width>,. . .) 


where <count> tells how many data elements 
have this format, <type> defines the data type 
(integer, fixed point, floating point, etc.), and 
<width> defines the number of character spaces 
allocated to a single data element. Each input and 
output statement must be associated with a FOR- 
MAT statement to define the exact data format to 
be used. 

In FORTH, it is possible to set such data up on a 
series of screens, which FORTH can then scan and 
compile directly into its dictionary. However, each 
variable must be defined separately as such, or else 
you must design your own handling words to de- 
fine the data array. FORTH is not designed to han- 
dle variable data in this fashion. 

In COBOL, such data must be in a file; you 
cannot define it as you can in BASIC. In addition, 
both C and Pascal require that variables be ex- 
plicitly defined, and work best if they are pre- 
allocated. 
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Sector 5: Direct User Input and Output. 


Some programs are designed to work by them- 
selves, while others must permit some interaction 
with the user. In BASIC, user interaction is accom- 
plished with the INPUT and PRINT statements with 
which you are already familiar. Other languages 
also allow various degrees of user interaction with 
the program. 

Interaction is easier with interpreters than with 
compilers, because the interpreter already has the 
necessary communications capabilities built into it 
to allow entry and display of the program itself. 
Since the interpreter is still present when the pro- 
gram is executed, its communication facilities are 
still available to the program. 

On the other hand, compiled programs need not 
have access to such communication facilities. The 
compiler, which had these capabilities, is not pres- 
ent in memory when the compiled program ex- 
ecutes. In batch processing systems, no interaction 
is possible, and the original versions of languages 
such as FORTRAN and COBOL simply did not 
include interactive capabilities. But later versions, 
written for microcomputers, as well as newer lan- 
guages not designed for batch processing, do in- 
clude some capabilities for communicating with the 
user while the program is running. 

In COBOL, the keywords are ACCEPT and DIS- 
PLAY, rather than INPUT and PRINT. The exact 
format required and the range of capabilities per- 
mitted these commands will vary according to the 
exact version of COBOL used. 
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In Pascal, the words READ and WRITE deal with 
single characters, while READLN and WRITELN 
handle complete lines of input and output. 

The primary user I/O commands in C are really 
functions. They are called SCANF() for input and 
PRINTF() for output. These are not defined ex- 
plicitly in the C language itself, but are included in 
the C compiler for a particular computer. There- 
fore, the exact capabilities of these functions will 
vary from one installation to the next. 

In FORTH, the input words are KEY or INKEY 
for single characters, or QUERY for a complete 
line. EMIT will output a single character: the word 
” will output a constant string, and the word . will 
print out the number currently on top of the stack. 

In FORTRAN, the READ and WRITE commands 
may be applied to the terminal (keyboard and 
screen) provided that your particular version of 
FORTRAN defines these and specifies device 
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numbers for them. You will probably still need 
FORMAT statements to go with the READ and 
WRITE statements. 

In all languages, the exact syntax may not be 
constant from compiler to compiler, or from com- 
puter to computer. To use any language on your 
computer, check the user’s manual for the lan- 
guage of your choice for the exact syntax required. 
In any event, user input and output will match the 
flowchart except for the formatting requirements of 
the command in the selected language. 


Sector 6: File Handling 


Whenever large amounts of data must be handled, 
and especially when that data has to be modified 
or manipulated in any way, you do not want to 
have to key it in manually using INPUT statements. 
Also, since the data will be modified by the pro- 
gram, it cannot be entered as DAIA statements 
within the program itself. Therefore, we want to 
keep it as a separate data file on disk or tape. 

As you have already learned, a data file is simply 
a collection of data stored under a single filename 
(on disk, in this case). The format of the stored data 
in the file was determined by the program that put 
it there, and any program trying to read the file 
must be written so that the data elements it expects 
to read will precisely match the data actually pres- 
ent. Otherwise, the program reading the file will 
only receive garbled nonsense. Most high-level lan- 
guages include file-handling capabilities to some 
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extent, although that will vary according to the de- 
sign of the language. 

BASIC is designed to handle files of any desired 
record length, any desired number of fields, and 
any desired number of entries. Of course, there are 
some practical limits on these values, but the pri- 
mary limitation is that the file size cannot exceed 
the available disk storage space. If you need that 
much space for data, your file will be unwieldy and 
hard to manage anyway. Files in BASIC may con- 
tain numbers and strings in any desired sequence 
or combination. They may be random access (any 
record available at any time) or sequential access 
(records must be read or written in sequence). 

FORTRAN was designed primarily for numerical 
operations. Accordingly, its file-handling capabilities 
are very limited. It can only handle numbers, and 
in sequential fashion. The meaning of each number 
and the relationships between numbers must be 
known to the programmer, since the file cannot 
contain such information. 

On the other hand, COBOL was specifically de- 
signed for business-type data processing. File han- 
dling is where COBOL excels. Therefore, COBOL 
has a full range of instructions for file manipulation. 

C, too, can handle files, as can some versions of 
Pascal. Be careful with Pascal, though, because 
some versions are deliberately simplified, and file- 
handling operations are often the first thing to go. 

FORTH is not generally a file-handling language. 
But it can access disk or other mass storage in a 
random fashion, in order to locate and load the 
“screens” that contain applications programs in the 
form of word definitions to be compiled. FORTH is 
not structured to handle data files. 

Before any data file on disk can be accessed, it 
must be opened. This process is performed by 
the operating system, and involves locating (or 
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creating) the file on the disk, and preparing the 
system to read or write records in the file. The basic 
flowchart step or Chapin diagram entry might be 


only: 
OPEN the file 


If the file is to be random access, the requirement 
to FIELD the file should also be stated. However, it 
might not be listed explicitly, and the actual field 
sizes normally won’t be listed at all. 

In BASIC, as you have already learned, we can 
code the OPEN statement as: 


OPEN <file#>,<device#>,<channel#>, 
” <filename >, <'type >, <direction >” 


Your program would have to keep track of the 
separate fields if random access is used. 

In COBOL, all programs are arranged in four 
divisions, or program sections. A program begins 
with an Identification Division, which gives program 
name, author, and any other required ID. Next 
comes the Environment Division. This division de- 
scribes any particular equipment or extra programs 
that may be required. It also names the files that 
will be used, and assigns these filenames to the 
keywords INFILE and OUFILE. The format of 
these assignments is: 
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SELECT INFILE ASSIGN TO “<filename>”. 
SELECT OUFILE ASSIGN TO “<filename>”. 


After the Environment Division comes the Data 
Division. Here, all variables and data storage space 
are declared. This includes a File Section, where 
the precise record and field structure of each file 
will be defined, and a Working-Storage Section, to 
define storage space, constants, etc. Additional sec- 
tions may also be defined. Finally, we have the 
Procedure Division, which contains the actual pro- 
gram itself. Here, you will find a statement like: 


OPEN INPUT INFILE, OUTPUT OUFILE. 


From now on, reading from the file will be by rec- 
ord name, and it is the programmer's responsibility 
to access fields by name. Writing to the output file 
is done by record name, after all fields are updated 
by name. 

In C, we must first define a pointer to the file. 
Then we can open the file. The file is always a 
sequential access file, which may be opened for 
read, write, or append. For an input file, we might 
use the sequence: 


FILE *IN; 
IN = FOPEN(‘“‘<filename>”,“R” ); 


From now on, all access to the file will be through 
the pointer IN, rather than through the 
<filename>. 

Random access can be performed in C, by using 
the function FSEEK() to set the file pointer to a 
specific character (NOT a record) in the file. 

In Pascal, files are defined essentially as a special 
kind of variable, using the keywords FILE and 
RECORD. For example, we might define our 
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CHEKBOOK data file as: 


TYPE CHECK = RECORD 
VAR CHECKBOOK: FILE OF CHECK; 


Then, the file can be accessed with the associated 
buffer pointer, which is inherently defined as 
CHECKBOOK . 

In FORTRAN, a file must be associated with a 
specific I/O device with a known device number. 
There are some variations in procedures, according 
to the computer and the specific version of FOR- 
TRAN, but it will be similar to the BASIC OPEN 
statement for a sequential access file (no specified 
record length and no random access). Once the file 
is OPENed, it can be accessed with the standard 
READ or WRITE statements, using appropriate 
FORMAT statements and the proper device # for 
that file. The data will be numeric, but the program 
must know ahead of time what form it will take 
(integer, fixed-point real, floating-point real, etc.). 

Once a file has been opened, reading or writing 
data is easy enough to code, and the code will 
correspond quite closely to the steps in the chart or 
diagram. Just be careful that your program code 
matches the syntax required by the compiler or 
interpreter for that language. 

When you have finished using a file, you must 
close it. This is always required, even if you have 
only read from the file. Closing the file makes sure 
that any data written to the file is actually trans- 
ferred to the disk, updates the file’s directory entry, 
and clears the file buffer in RAM. Even if you have 
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only read from the file, closing it informs the sys- 
tem that this file is no longer in use, and it frees the 
system buffer for other uses. 

Before closing the file, make sure that you have 
written all desired data to it, or read all desired data 
from it. The system will only permit access to an 
open file, so complete all of your accesses while it 
is still open. 


Sector 7: Control Structures. 


Both processing instructions and I/O instructions 
(with the exception of OPENing a file) translate 
rather easily from flowchart or diagram form to 
program code. About the only requirement is that 
you be careful to use the code syntax and keyword 
spelling required by the compiler or interpreter for 
that language. 

Some very simple control structures are equally 
easy to translate. For example, very basic IF ... 
THEN or IF... THEN. . . ELSE structures gener- 
ally translate nicely. More complex choices such as 
case statements may or may not translate that 
easily. However, program loops, especially indefi- 
nite loops, require some very careful thought dur- 
ing the coding process. 

We looked at the various types of control struc- 
tures earlier in this module. Rather than just repeat 
them here, we will see how they can be used in a 
number of practical applications in Track 5. 
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PRACTICAL PROGRAM ROUTINES 


Any practical program, regardless of language, in- 
cludes all three types of commands (processing, 
I/O, and control) in various combinations and se- 
quences. The task performed by the program will 
be determined not only by what instructions are 
used, but also by the order in which they appear. 
Furthermore, a complete program may be viewed 
as a series of individual tasks, or routines, com- 
bined in a particular sequence to perform the over- 
all task. 

When you code a program, it is often helpful to 
keep the complete task performed by a given rou- 
tine in mind as you code that routine. Thus the 
coding of a program from its flowchart or Chapin 
diagram (or other graphic representation) is not 
precisely a one-to-one transfer of diagram step to 
program instruction, but rather a transfer of a co- 
herent group of steps to a coherent sequence of 
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instructions. This means that you should keep in 
mind the logic of the routine as well as the syntax 
of an individual command. 

To assist in this, you should become familiar with 
a number of commonly-required logical sequences 
and routines. Then you can use these sequences 
with only small adjustments in any program that 
requires them. 

We do not have a program on your program disk 
to go with this Track. If at any time you wish to try 
out a program or routine that we list in this Track, 
by all means go ahead and do so, using whatever 
language is available to you. Our program exam- 
ples on disk are in BASIC because we cannot be 
sure that any other language will be universally 
available, but the routines for other languages are 
equally valid. If you try these programs in various 
languages, you will learn for yourself how similar 
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different languages really are, and how a common 
program design procedure can apply to any com- 
puter language. 


Sector 1: Finding an Arithmetic Average 


A very common requirement when dealing with 
numbers is to find the average of a list of numbers. 
This happens in classrooms (grade-point average), 
business applications (compare present perform- 
ance with average over time), scientific applications 
(average incoming data), and specific mathematical 
applications. 

Of course, we know how to calculate the average 
of a group of numbers. We first count the numbers, 
then we add them all together and divide by the 
count. Thus, for three numbers A, B, and C, we 
could write the program line: 


AVERAGE = (A + B + C)/3 


But what happens if we don’t know ahead of time 
just how many numbers we want to average? How 
can we program this? This is a task for an indefinite 
program loop, which will terminate when it receives 
an end-of-data marker in place of another number. 

Figure 5-1 shows a flowchart for this task. For 
comparison purposes, Figure 5-2 shows the equiv- 
alent Chapin diagram. In both diagrams, we have 
included provision for the possibility that there will 
be no numbers to average. In the Chapin diagram, 
this is shown by the “DO WHILE” line at the top of 
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START 


COUNT=0 


AVERAGE= 
SUM/COUNT 


Figure 5-1. Flowchart of a routine to average an 
unknown count of numbers. 


COUNT=0 
SUM=0 
DO WHILE NOT END OF DATA 


INPUT A NUMBER 


Ls, 
NA Oe 
pe One 


Figure 5-2. Chapin diagram for the averaging 
routine. 
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the loop. If an end-of-data marker is found at the 
start, the vertical path is followed immediately, and 
the steps in the loop are bypassed. This is dis- 
tinguished from the loop ending with a “DO UN- 
TIL” line and a vertical path back to the start of the 
loop. A “DO UNTIL” loop is always executed at 
least once. A “DO WHILE” loop may never be 
executed. In the flowchart, this is indicated by plac- 
ing the end-of-data test ahead of the mathematical 
processing block. Essentially, end-of-data is en- 
countered during an attempt to read a number, 
when there are no more numbers to read. 

We have not indicated the source of the numbers 
to be averaged. They may be typed in by the user, 
or they may be in a file. They may even be in 
DATA statements, if the language permits that. We 
may have to adjust the INPUT block according to 
the final method of input, and the end-of-data 
marker will also depend on the method of input, 
but the actual method of averaging will remain the 
same. For the sake of demonstration, where we 
have no data file to act as a source of information, 
we will assume that the data will be input from the 
keyboard, and that the <enter> key by itself will 
indicate the end of the data. We will write the aver- 
age routine as a subroutine (or function or pro- 
cedure, depending on the language). The main 
routine will be a driver program that will also print 
out the results. 

The BASIC program to accomplish this is: 


100 PRINT *[CS]INPUT NUMBERS TO BE 
AVERAGED.” 

110 PRINT “PRESS (RETURN) TO END 
ENTRY.” 
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120 GOSUB 1000 

130 PRINT “[CS]YOU TYPED IN’;COUNT; 
“NUMBERS.” 

140 PRINT “THEIR AVERAGE IS”;AVERAGE 

150 END 


1000 COUNT = 0:SUM = 0 
1010 INPUT N$ 


1020 IF N$ = “” THEN 1100 

1030 N = VAL(N$) 

1040 SUM = SUM + N 

1050 COUNT = COUNT + 1 

1060 GOTO 1010 

1100 IF COUNT = 0 THEN AVERAGE = 
0:RETURN 

1110 AVERAGE = SUM/COUNT 

1120 RETURN 


Of course, our selection of line numbers is arbi- 
trary, and you can change them if ‘you wish. 
However, this sequence is perfectly satisfactory. 
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In FORTRAN, the subroutine must be declared 
first, and we must decide what range of numbers 
we will use. For the sake of appearance and sim- 
plicity, we'll use a format of F10.4 (10 columns 
allocated, with a maximum of four digits after the 
decimal point). Also, before you try running this 
program, check our selection of device numbers in 
the READ and WRITE statements. Depending on 
your version of FORTRAN, you may need to adjust 
the syntax or device numbers for these statements. 
Also, your version of FORTRAN may require spe- 
cific control statements and program identification. 
Also, FORTRAN cannot input strings, so we will 
use an input value of O to terminate entry. With 
these points in mind, the FORTRAN program to 
calculate this average is: 


SUBROUTINE AVERAGE (ICOUNT, AVER) 
ICOUNT = 0 
SUM = 0 
20 READ (1,100) ANUMB 
100 FORMAT (F10.4) 
IF (ANUMB) 10,50,10 
10 SUM = SUM + ANUMB 
ICOUNT = ICOUNT + 1 
GOTO 20 
50 AVER = 0 
IF (ICOUNT) 60,70,60 
60 AVER = SUM/FLOAT(ICOUNT) 
70 RETURN 


C MAIN PROGRAM 
WRITE (1,200) 
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200 FORMAT (29HINPUT NUMBERS TO BE 
AVERAGED. ) 
WRITE (1,300) 

300 FORMAT (25H ENTER ZERO TO END 
ENTRY.) 
CALL AVERAGE (ICOUNT, AVER) 
WRITE (1,400) ICOUNT 

400 FORMAT (13HYOU TYPED IN ,14,9H 
NUMBERS. ) 
WRITE (1,500) AVER 

500 FORMAT (17HTHEIR AVERAGE IS ,F10.4) 
END 


In FORTRAN, unless otherwise declared, vari- 
able names beginning with the letters I through N 
are assumed to be integers, while all others are 
assumed to be real. You can remember this if you 
note that | and N are the first two letters in the 
word INTEGER. Most arithmetic functions cannot 
be performed between an integer and a real 
number, so the FLOAT function is used to convert 
ICOUNT to a real number for this calculation (line 
60). 
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In the FORMAT statements, the letter H pre- 
ceded by a number indicates a series of characters 
to be output. Here, the “H” stands for “Hollerith,” 
and the number indicates how many characters are 
to be output. This is the only way FORTRAN per- 
mits character output. | indicates integer output, 
while F denotes a real number in fixed-point for- 
mat. 

Note that in the FORTRAN subroutine, we did 
not keep the line numbers in sequence. This is 
perfectly acceptable; line numbers merely identify 
lines, they do not determine the order of execution. 

COBOL does not work well with numeric opera- 
tions, so we will make no effort to code this prob- 
lem in COBOL. 

In Pascal, we must define the subroutine as a 
procedure before we can use it. Also, we must 
write the program in a more structured format than 
is required for either BASIC or FORTRAN. The 
resulting program is: 
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PROGRAM Average_Numbers; 
VAR Average, Count : REAL; 


PROCEDURE Calculate; 
VAR 
Sum, Number : REAL; 


BEGIN 
Sum:= =I: 
Count := —1; 
Number := 1; 
WHILE Number <> 0 DO 
BEGIN 
Sum := Sum + Number; 
Count := Count + 1; 
READLN(Number); 
END; 
Average := 0; 
IF Count > 0 
Average := Sum/Count; 


END; { Calculate } 


BEGIN { Main Program } 


PAGE(OUTPUT); { Clear the screen } 
GOTOXY (1,4); 

WRITELN(‘Enter numbers to be 
averaged. ’); 

WRITELN(‘Enter zero (0) to end.’); 
Calculate; 


PAGE(OUTPUT); 

WRITELN(‘You entered ’,Count,’ 

numbers. ’); 

WRITELN( ‘Their average is ’ Average); 
END. { Average_Numbers } 


Note the presence of a semicolon (;) at the end 
of most lines in this program. This is standard Pas- 
cal nomenclature and is required at the end of most 
program lines. A few statements do not require a 
semicolon, but the presence of one will do no 
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harm. Only the final END statement has a period 
after it. Upper and lower case letters may be mixed 
in any desired way; they are the same to Pascal. 

The summing loop in Pascal was slightly differ- 
ent, because we must have a non-zero value for 
“Number” the first time through the loop. To do 
this, we adjusted the initial values of these variables 
so that they would be zero when the first real 
number was entered. 

The C language is similar in many respects to 
Pascal, except that in C the main program (func- 
tion) is always listed first, rather than last. Also, 
braces are not used for comments in C; rather they 
take the place of the BEGIN and END words. The 
resulting program in C is: 

#include <stdio.h> /* include standard I/O 
package */ 

main() /* the main function always comes first */ 
{ 


float sum, average, number, count; 


printf(“Type in some numbers, and I will 
average them. \n”); 

printf(“Type 0 to end the list.\n”); 
average(); 

printf(“You typed in %f numbers. ”,count); 
printf(“Their average is %f.\n” average); 


} 


average( ) 
routine */ 


{ 


/* now we define the averaging 
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number = 1.0: 

WHILE (number <>0.0) { 
count-+- =: 
sum = sum + number; 


scanf(“%f’ ,&number); 
} 

IF ( count? 0:03) 
average = 0.0; 

EESE 
average = sum/count; 


} 


Except for differences in syntax (the actual key- 
words and the way they are used), the basic 
difference between C and Pascal is that a program 
in C is written “top-down,” while in Pascal it is 
written “bottom-up.” That is, In C the main pro- 
gram segment or loop appears first, and then all of 
the internal routines and functions are defined. In 
Pascal, you must define the innermost routines 
first, and then work upwards. 

This difference is not normally a problem, so 
long as the programmer uses the chosen language 
correctly. Flowcharts and Chapin diagrams are nor- 
mally drawn in a “top-down” fashion, just because 
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it is usually easier to keep the program design or- 
ganized that way. However, once the chart is drawn 
and all internal routines, functions, and subroutines 
are defined, it is just as easy to code them bottom 
up as to code them top down. 

Another language that requires a bottom-up pro- 
gram structure is FORTH. The standard structure of 
this language also restricts numbers to integers. 
Single-precision numbers are 16 bits long, and 
therefore have decimal values in the range 
— 32768 to +32767. Double-precision operations 
are also possible, using 32-bit integers to permit 
decimal numbers in the range — 2,147,483,648 to 
+ 2,147,483,647. It is posible to write FORTH 
words to handle floating-point (real) numbers, and 
some versions of FORTH have them predefined. 
But for general use we should restrict ourselves to 
16-bit integers only. On that basis, we might define 
our averaging program in FORTH as follows: 


0 VARIABLE SUM 
0 VARIABLE COUNT 
: GET_NUMB QUERY BL WORD HERE 
NUMBER DROP ; 
: COMPUTE_SUM 
0 SUM ! 
0 COUNT ! 
BEGIN 
GET_NUMB —DUP 
WHILE 
SUM +! 
1 COUNT +! 
REPEAT ; 
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: COMPUTE_AVERAGE 


COUNT @ 

IF 
SUM @ 
COUNT @ 
Ou/ 

ELSE 
0 

THEN ; 


: AVERAGE 


PAGE .“‘ Type in some integers to be 
averaged.” CR 
““ Do not use fractions. Press <enter> after 
each number.” 
CR .“ Enter zero (0) to end the list.” 
COMPUTE_SUM 
COMPUTE_AVERAGE 

CR CR .“ You typed in ” COUNT ? ” 
numbers.” CR 

. Their average is”. ; 


In FORTH, a “word” is defined as a string of 
characters surrounded by spaces. We wrote the 
main program words in structured format for read- 
ability, but this is not necessary as far as FORTH is 
concerned. As long as there is at least one space 
between separate words, that is sufficient. Also, 
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there is generally a limit of 80 characters in any line 
typed in from the keyboard. In the above program, 
the word : begins the compilation of a new word 
into the dictionary, and the word ; completes the 
new definition. The word immediately following the 
: word will be the name of the new word, and the 
rest of the words up to the ; word become the 
definition of the new word. 


Sector 2: Sorting a List of Values 


One of the most commonly-required functions in 
computer programs is to sort data into a logical 
sequence. The data may be numbers to be placed 
in numerical order, or it may be names to be ar- 
ranged into alphabetical order. The required se- 
quence may be ascending order or descending 
order. Before we can look at sorting, we must look 
at a special kind of variable known as the array 
variable. 

To understand what an array is and why it is 
needed, let’s take a look at the procedure required 
to sort three variables, A, B, and C, into ascending 
order. What this means is that we want to arrange 
these variables and exchange values, if necessary, 
so that the smallest number will be in variable A, 
the next one in variable B, and the largest in vari- 
able C. If we assume that numbers have already 
been assigned to these variables, Figure 5-3 shows 
the flowchart for sorting them into ascending order. 

Note that we need three comparisons to se- 
quence these three values. The last comparison 
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Figure 5-3. Flowchart for sorting three variables. 
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looks exactly like the first, and you may wonder 
why it would be needed. However, if B and C had 
to be exchanged, the original value of A may be 
larger than the new value of B, even if the original 
test failed. Therefore, the third test must be made. 
Essentially, the first two tests serve to put the high- 
est of the three numbers into variable C. The final 
test makes sure that the smallest is in variable A. 

Each of the three tests is the same in format, but 
uses different variables. Because of the different 
variable names, we can’t just use the same instruc- 
tions over and over again to make the tests. We 
certainly can’t define a FOR . .. NEXT loop that 
will start with one variable name and sequence 
through others to the last name. BASIC won’t even 
let you use a string variable as the index for such a 
loop, and even so you can’t use a string variable to 
identify another variable name. 

Of course, with only three numbers to sort (or 
names, if we use string variables), this kind of pro- 
gram is not too difficult. But what happens if we 
have 100 numbers? or 1000? How about 10,000? 
With three numbers, we needed three com- 
parisons. With four numbers we would need 3 + 2 
+ 1 = 6 comparisons. With five numbers we 
would need 4 + 3 + 2 + 1 = 10 comparisons. 
With six numbers it becomes 15 comparisons. Who 
would want to code that many comparisons indi- 
vidually, let alone the number you would need for 
thousands of numbers to be sorted. 

One thing we could do is define a subroutine to 
go through the entire sequence of comparing adja- 
cent numbers once, and then call that routine one 
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fewer times than there are numbers to compare. 
This would mean many unnecessary comparisons, 
but it would shorten the program. Even so, thou- 
sands of individual comparisons is far too many. 
Also, you may not know ahead of time just how 
many numbers you will be dealing with, or how 
large they may be. What we need is a way to store 
all of the numbers or names under a single variable 
name and refer to individual numbers by means of 
a subscript attached to the variable name. The re- 
sulting subscripted variable would then be an array 
variable. 

In BASIC, an array variable must be dimen- 
sioned before it can be used. This is done with the 
DIM statement: 


DIM N(100) 
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This statement defines a one-dimensional array 
whose maximum permitted subscript is 100. De- 
pending on the exact version of BASIC used, the 
lowest allowed subscript may be either 0 or 1. If an 
array variable is used without a DIM statement, it 
will be allocated space for elements up to number 
10, just as if you had given it a: 


DIM N(10) 


command explicitly. Once dimensioned either im- 
plicitly or explicitly, and array cannot be re-dimen- 
sioned; the storage space is already allocated and 
cannot be changed. 

To see how we can use an array while sorting 
numbers, consider the following program se- 
quence: 


FOR I = MAX TO 2 STEP —1 

FOR J = 1TOI-1 

IF N(J) > N(J+1) THEN SWAP N(J),N(J +1) 
NEXT J 

NEXT I 


Here we start by placing the highest number at 
the highest subscript position. Then we place the 
next-highest number at the next location, and so 
on. 

Some versions of BASIC do not have the SWAP 
command, although most later versions do support 
it. If your version does not include SWAP, use the 
following sequence instead: 
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IF N(J) > N(J+1) THEN TEMP = N(J):N(J) = 
N(J +1):N(J +1) = TEMP 


Of course, this routine supposes that MAX has 
already been defined as the number of values to 
sort and that the array N has already been appro- 
priately dimensioned. It also assumes that values 
have already been read into successive elements of 
the array. 

The advantage of using arrays is that the sub- 
script may be calculated, or may be the index of a 
loop (as above), or may be a numeric variable or 
expression of any type. This allows you to calculate 
which element you want out of the entire array, or 
to specify it by number when you are typing some- 
thing in from the keyboard. The use of arrays can 
also simplify access to fields in a random-access 
file. In fact, later on we will show you how an array 
can be used in the PHONBOOK program to di- 
rectly select the desired field for scanning the file 
for a match. 

The particular sorting technique shown above is 
known as a “bubble” sort, because it causes num- 
bers to travel, one at a time, up a “bubble” to their 
correct positions in the sequence, starting with the 
highest number and working backwards. This is 
not the most efficient sorting technique, but it is 
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satisfactory for short lists of numbers, and is easier 
to understand (at first) than other sorting tech- 
niques. Therefore, we will limit ourselves to the 
bubble sort for this module. 

Different versions of BASIC (and other lan- 
guages) have different limitations on array vari- 
ables. Early versions of BASIC allowed only one 
dimension (a single subscript). Later versions al- 
lowed two dimensions [eg, N(I,J) or A$(P.Q)]. 
Newer versions allow as many dimensions as you 
may need to use, with successive subscripts sepa- 
rated by commas. But large arrays use up memory 
at a rapid pace, so don’t make an array bigger than 
you need to. 

Once the array has been defined, your program 
can proceed to enter numbers into it, and then to 
operate on those numbers as desired. Use a FOR 
... NEXT loop to enter numbers. For example, in 
BASIC, you might enter 100 numbers from the 
keyboard using this sequence: 


DIM ARRAY(100) 

PRINT “Input 100 numbers, please:” 
FOR I=1 TO 100 

INPUT ARRAY (1) 

NEXT I 


Then your program can proceed to work with 
these numbers in any desired fashion. 

A possible problem exists if you don’t know 
ahead of time just how many numbers must be 
processed. In that case, you must know the max- 
imum possible requirement and dimension the ar- 
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ray accordingly. Then, if you have fewer numbers 
to work with, you simply use whatever fraction of 
the array that may be required. 

As we mentioned earlier, sorting routines can 
work on either numbers or character strings, such 
as names. Since the ASCII codes assigned to letters 
are in sequence, these codes can easily be used to 
sort a list into alphabetical order. In addition, sort- 
ing may be required by many different programs in 
any language. In Pascal, for example, we would 
have to declare variables and there would be some 
minor variations from the syntax of the BASIC rou- 
tine, but it would be very similar: 


VAR I,J,N : INTEGER; 
TEMP : REAL; 
A : ARRAY[1 . . 100] OF REAL; 


FOR!I:= 1TON — 1 DO 
FOR J== 1 TON: - 1 DO 
IF A[J] > A[J + 1] THEN 


BEGIN 
TEMP := AJ]; 
Al(J] := AlJ +1); 
A[{J +1] := TEMP; 
END; 


Pascal does not require NEXT statements to go 
with FOR, because it assumes that only the next 
statement will be repeated, unless it is a procedure 
that starts with BEGIN. The same is true of the IF 
statement. Also, note that Pascal uses square 
brackets [] to denote subscripts, rather than paren- 
theses (). 
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Figures 5-4 and 5-5 show bubble sort routines 
for C and FORTRAN, respectively. As you can see 
by comparing these routines, the essential pro- 
cedure is exactly the same in each case; the only 
differences are those required by the language it- 
self, according to its syntax. 

FORTH can use a similar routine, assuming an 
ARRAY word has previously been compiled to gen- 
erate and handle arrays. If we allow this assump- 
tion, the routine shown in Figure 5-6 will sort the 
array into ascending order. The FORTH routine 
uses a few standard words that are not available in 


sort (array, limit) 
float array []; 
int limit; 
{ 
int top, check; 
float temp; 
for ( top = 1; top < limit; top+ + ) 
for ( check = 1; check <= limit — top; 


check+ + ) 
if ( array[check] > array[check+ 1] 


temp = array[check]; 
array[check] = array[check + 1]; 
array[check+ 1] = temp; 


Figure 5-4. A bubble sort routine for C. 
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other languages. For example, the FORTH word | 
automatically returns the current value of the inner- 
most active DO loop. If used, J returns the index 
value of the next outer DO loop, and K returns the 
index of the next one. The word LIST used in this 
routine is assumed to be a predefined array word 
that will return the address of the appropriate array 
element when it is called. 

COBOL does not require a special sorting rou- 
tine. Sorting of entries in files is so commonly re- 
quired that COBOL includes the command SORT, 
which performs the entire task itself. 

We could go on indefinitely with program exam- 
ples and typical control structures, but to learn 
them most effectively, you must actually use them. 
So we will work with practical programs next in 
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DO 1001 = 1, MAX~1 
DO 100 J = 1, MAX-1 
IF (ARRAY(J) — ARRAY(J+1)) 100, 100, 


50 
50 TEMP = ARRAY(J) 
ARRAY(J) = ARRAY(J+ 1) 
ARRAY(J+1) = TEMP 
100 CONTINUE 


Figure 5-5. A bubble sort routine in FORTRAN. 


TOP 
0 DO 
TOP! — 0DO 
I LIST @11+ LIST @ > 
IF 


I LIST @11+ LIST @ 
ILIST!11+ LIST! 
THEN 
LOOP 
LOOP 


Figure 5-6. A bubble sort routine in FORTH. 
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PRACTICAL PROGRAMMING EXPERIENCE 


In many ways, coding a program is just the next 
step in detailing a flowchart or other diagram. 
When you code the program, you are adding the 
final detail required by the compiler, interpreter, or 
assembler in order to actually understand the pro- 
gram and either execute it or translate it into ma- 
chine code. The difference is that you are no 
longer working with a chart or graphical program 
representation; you must translate your chart into 
the format required by the language you are using. 

As you have already seen, a fully detailed chart 
translates mostly on a one-to-one basis from 
graphic step to program instruction. There are a 
few exceptions (noticeably in file handling and con- 
trol structures), but even these are relatively direct 
and can be translated easily if the programmer 
pays attention to the required syntax of the control 
structure involved. There are still a few techniques 
which can be used to keep the coding process as 
simple and straightforward as possible. These are 
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best learned in actual practice, so we will provide 
some practice problems, using sample data on your 
program disk. 


Sector 1: The Programming Form 


Any computer program consists of a list of instruc- 
tions for the computer to perform. The task to be 
performed by the computer is defined by the actual 
instructions in the list and by the order in which 
they appear. The instruction content and sequence 
have already been defined as the main task of pro- 
gram design, which we have explored in previous 
modules. However, in coding the program, we 
want to make sure that the organization of the pro- 
gram is clear, and that it matches the previously 
diagrammed organization. Also, we want to be sure 
that we can easily read our program code later on, 
to allow for corrections and possible updates. 
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To help accomplish this, we do not generally sit 
down in front of the computer and type in the 
program with only a flowchart or other diagram to 
work from. Instead, we will first code the program 
on paper in appropriate format. Then, when we 
are satisfied with the coding on paper, we can pro- 
ceed to copy the program code from paper to the 
computer. 

Of course, you can use any ordinary piece of 
paper for this purpose. But it is much easier to use 
a printed form that helps to keep your program 
code organized. For example, you undoubtedly 
noticed that our program code examples in earlier 
tracks in this module often used indentation to 
show different levels of nested control structures or 


54 


F G 


Figure 6-1. The blank programming form provided in this module. 


groups of instructions to be executed as a result of 
a control statement. This is common practice with 
many programming languages because it helps the 
programmer to keep track of which control level 
the program is currently using. Other languages, 
such as FORTRAN and BASIC, do not call for such 
indentation and are often harder to read as a result. 

Preprinted programming forms have been devel- 
oped for every programming language, with boxes, 
lines, and spaces appropriate to the fields required 
by that particular language. Unfortunately, the ir- 
regular spacing of such a form generally makes it 
unsuitable for any other language. To help over- 
come this problem, we have designed a “generic” 
programming form. You received a pad of these 
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LANGUAGE PAGE | OF | 
DATE MM/DD/y y 
ra H l J 


Figure 6-2. Coding the bubble sort routine in FORTH, using the form. 


forms with this module. If you have not already 
examined the form, locate it and look it over now. 
Figure 6-1 shows the layout of this form. 

This programming form consists of a header sec- 
tion and a main body. The header section is used 
to identify the program, its author, and the lan- 
guage in which it was coded, as well as page num- 
bers and the coding date. This information will help 
you to put pages of a single program into the cor- 
rect sequence, and to pick which pages go with 
what program, in case the sheets get scrambled or 
dropped for any reason. 

The main body of the form is used for the pro- 
gram code itself. This form consists of a number of 
lines (27 is what we had room for, but it doesn’t 
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really matter), divided into ten equal-width col- 
umns. Each line on the form will hold a single line 
of program code. Different columns will be used for 
different purposes according to the coding lan- 
guage, so we simply designated them A through J, 
and we will use these letters to refer to the 
columns. 

To use the form, simply write the program code 
onto the form using one line per program code 
line, starting in the appropriate column. Use the 
column lines to separate logical sections of the pro- 
gram code. For example, in BASIC and FOR- 
TRAN, you would use column A for line numbers 
and (in FORTRAN) comment markers only. The 
actual program code would start in column B. You 
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might also want to place only the main command 
keyword in column B, for even greater reading 
clarity. 

In Pascal and C, you would use successive col- 
umns to mark indents into inner control structures. 
The same arrangement will work with FORTH. 

Each column is wide enough to hold six to ten 
characters. We will show eight characters per col- 
umn in our figures, as a reasonable compromise. 
We suggest that you print neatly when writing pro- 
gram code on a form like this one. 

Figure 6-2 shows a typical program code layout 
on our form. For this example, we have used the 
FORTH version of the bubble sort routine from 
Figure 5-6. This figure shows how we will display 
our program code examples. We have added the : 
and ; words required to make this a complete word 
definition, as well as the name, SORT, of this new 
word. 

In FORTH, we don’t place a single word in each 
column. However, we do try to keep logical groups 
of words together, such as the sequence: | LIST @. 
This helps to define the logic of the program on the 
coding form. Similar considerations are possible 
with other languages. 


Sector 2: Designing a Statistical Analysis 
Program 
One of the files on your program disk for Module 4 


is named NUMBERS.DAT. This file contains a list 
of numbers generated at random. All numbers are 
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INITIALIZE 


| DISPLAY 
RESULTS 


Figure 6-3. The first-level flowchart for the statis- 
tical program. 


less than 100, with a maximum of three digits past 
the decimal point. That is, the largest possible 
number in the file is 99.999, and the smallest possi- 
ble number is 0. All numbers are positive. There is 
an uncertain number of such numbers in the file, 
but there will not be more than 100 numbers. 
Therefore, you can DIMension your array for a 
maximum of 100 elements, using an instruction 
such as: 


DIM N(100) 


The last number in the file is -1, to mark the end 
of the data in this file. This number is NOT part of 
the data itself, and should not be included in the 
handling of the data. 

As a demonstration problem, we will design a 
program to read the numbers in this file, count 
them, sort them into ascending order, and find 
their average. We will also find the median value 
(the number in the middle of the sorted list). 

Figure 6-3 shows the first round flowchart for this 
program. Basically, it is very similar to any prelimi- 
nary flowchart for a wide range of programs. It will 
become fully specialized as we add detail to it. To 
add this detail, we will examine each step sepa- 
rately. 
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~ OPEN DATA. 
FILE FOR : 
SEQUENTIAL INPUT | 


READ DATA 
ELEMENTS INTO 
THE ARRAY 


CLOSE THE 
PILE 


| SORT THE 
[FIND THE | 
fo AVERAGE 
FIND THE 
MEDIAN _ 


DISPLAY THE SORTED LIST | 
| AVERAGE, AND MEDIAN | 
[AS WELL AS THE COUNT | 


Figure 6-4. The expanded flowchart for the sta- 
tistical program. 
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Step 1: Initialize. This is where we define any 
variables that we will need to have predefined. In 
this case, using BASIC, the only variable we must 
predefine is the array variable. Therefore, the Ini- 
tialization phase consists only of this one item. In 
some languages, such as Pascal, this step would 
also include predefining all variables that are re- 
quired by the program as a whole. 

Step 2: Read Data File. Here we must per- 
form all operations relevant to obtaining the neces- 
sary data from the data file and placing it into the 
numeric array where it can be processed by the 
program. This will include opening the file, reading 
the data into the array, and then closing the file. 

Step 3. Process the Data. This is where the 
program does the real task for which it is being 
designed. In this case, the program must first sort 
the numbers into ascending order. Then it will 
compute the average of the numbers and finally 
determine the median value. 

Step 4. Display the Results. Now ‘that the 
processing is done, we can display the final results. 
We will want to indicate how many numbers were 
read from the file, display the sorted list, and pro- 
vide the average and median values. This will end 
the program. 

Figure 6-4 shows the expanded flowchart for this 
program. We have not yet defined each activity in 
full detail, but we have spread out the basic steps 
and specified them in greater detail. The next step 
is to add the detailed control structures to the 
flowchart, to define exactly how we will accomplish 
each step. 

No further detail is needed for the DIMENSION 
block; in any language, this is merely a predefini- 
tion of the space required by the array within the 
program. This will be accomplished by a declara- 
tion statement at the beginning of the program. 
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Opening and reading the data file requires a sub- 
stantial amount of additional definition. This is es- 
pecially true of the reading process. We will need 
some kind of program loop to read the data ele- 
ments one at a time and to specify the array ele- 
ment into which each individual number will 
initially be stored. Since we have a fixed ceiling of 
100 elements in the problem definition, we can use 
a definite loop to accomplish this. 

Figure 6-5 shows the detailed flowchart for this 
section. Note that this flowchart does not allow for 
the possibility that there may be too many data 
elements in the file. Since the problem statement 
specified that this would not be the case, and in fact 
there are fewer than 100 numbers in the file, this 
will not cause any difficulties. A general-purpose 
program would have to add error-checking to test 
for this possibility. 

We have already looked at sorting and averaging 
procedures, both as charts and program code, so 
we will not reproduce these items here. In our pro- 
gram, we will perform these operations in sub- 
routines, which will be essentially identical to the 
code we examined earlier. The median value in the 
sorted list is simply that value closest to the center 
of the list. Thus, in a list of 10 elements, the median 
value is simply the 5th element. 

To allow for the possibility of an odd number of 
elements, we will add one to the count of num- 
bers before we divide by two. This will give us the 
6th element as the median value of an 11- 
element list or a 12-element list. The 5th element 
is NOT in the center of an 11-element list (con- 
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' OPEN *I* FILE #ae 


READ NUMBER _ 
INTO I'TH 
ARRAY ELEMENT 


7] LAST ELEMENT [oe 
' IS #1-I 
. CLOSE THE FILE (aaa 


Figure 6-5. The detailed procedure for reading 
data elements from the file. 
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struct such a list and see which element is in the 
middle of it). 

Displaying the results consists only of outputting 
the results of the calculations, along with a small 
amount of text to indicate which answer is which. 
The flowchart in Figure 6-4 already indicates the 
required output clearly enough. 

Now we can begin to code this program, using 
the flowcharts of Figures 6-4 and 6-5 as models. 
Before you begin this process, make sure that your 
computer is available and that you have started 
BASIC. If any basic program is currently in mem- 
ory, type the command: 


NEW <return> 


to erase it and start with cleared memory. Always 
make sure that any remnants of old programs can- 
not interfere when you type in a new one. 

It is good programming practice to assign differ- 
ent groups of line numbers to different sections of 
the program. Accordingly, we will assign line num- 
bers in the 100s to the initialization section. We will 
also start this section with a comment line. To do 
this, type in the following program lines: 


100 REM INITIALIZATION SECTION. 
110 DIM NUMBERS(100) 


Now, we must open, read, and close the data 
file. We will start with line 200, and again we will 
use a comment line. Type in the following program 
lines: 
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200 READ THE DATA FILE. 

210 OPEN’8,8,8,"NUMBERS.DAT” 

220 FOR I = 1 TO 100 

230 INPUT#8, NUMBERS(I) 

240 IF NUMBERS(I) = — 1 THEN LAST 
= I—1:GOTO 260 

250 NEXT | 

260 CLOSE 8 


Once these program lines have been executed, 
the complete data file will reside in memory, and 
we will be able to process it in any desired fashion. 
We already stated that we want to use subroutines 
to do the sorting and the averaging. We already 
have the number of valid entries (LAST, calculated 
in line 240 above), so we can directly report the 
number of entries and we can easily find the me- 
dian value after the list has been sorted. 

At this point, we have a choice: we can use 
separate subroutines to sort the list and find the 
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average, or we can combine the two functions into 
a single subroutine. As a matter of good program- 
ming practice, we will keep the two subroutines 
separate. This will permit us to use either sub- 
routine by itself, in this or other programs, without 
having to recode it in the future. In the main pro- 
gram, therefore, we will place subroutine calls with 
line numbers in the 300s. Type in the following 
lines: 


300 REM CALL PROCESSING SUBROU- 
TINES. 

310 GOSUB 1000 

320 GOSUB 2000 


The line numbers for the subroutines were as- 
signed arbitrarily, but they were selected to be 
greater than any line numbers required by the main 
program. We didn’t even have to call them in 
order; we could have reversed lines 310 and 320. 
However, just as a reminder for the future, we 
should put in the comment lines with these line 
numbers. Do so now: 


1000 REM SORTING SUBROUTINE. 
2000 REM AVERAGING SUBROUTINE. 


Don’t worry about typing in lines out of se- 
quence; as you already know, BASIC will insert 
each new line into the location in the program 
called for by its line number. 

Now that we have the list sorted and have calcu- 
lated the average, we can proceed to display the 
results. We have not yet found the median value, 
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but we can specify that directly; we don’t have to 
calculate it. Therefore, we will proceed to the dis- 
play function of the program, beginning with line 
400: 


400 REM DISPLAY THE RESULTS. 

410 OPEN 4, 4 

420 PRINT#4,"THE SORTED LIST OF 
NUMBERS IS:” 

430 FOR I=1 TO LAST 

440 PRINT#4,NUMBERS(I) 

450 NEXT I 

460 PRINT#4:PRINT#4,” THERE ARE”;LAST; 
“NUMBERS IN THE LIST.” 

470 PRINT#4,”THE AVERAGE VALUE IS”, 
AVERAGE 

480 PRINT#4,”THE MEDIAN VALUE IS’; 
NUMBERS((LAST +1)/2) 

490 CLOSE 4 


We specified in these lines that the output go to 
the printer instead of the screen. If you do not have 
a printer available, delete lines 410 and 490, and 
delete the “#4” specification following each PRINT 
command. The output will then go to the screen, but 
you will not be able to see all of the numbers atone 
time. 
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go to the screen instead. However, you will not be 
able to see the entire list of numbers in this case. 

The main program has now accomplished every- 
thing we wanted it to do. It has read the initial data, 
called the processing routines, and displayed the 
results. Now we can end the main program with a 
final line: 


500 END 


This line is necessary in this case, because we 
will be placing the subroutines beyond it. If we left 
out the END statement, BASIC would continue to 
execute the subroutines as if they were in line as 
part of the main program. When BASIC found a 
RETURN statement without a prior GOSUB, it 
would not find any place to RETURN to, and 
would therefore issue an error message and then 
halt. 

We have already looked at sorting routines in 
several languages, including BASIC, so we will not 
discuss the routine here. Simply enter the following 
lines, which you should recognize from Track 5: 


1010 FOR J = 1 TOLAST - 1 

1020 FOR K = 1 TO LAST — J 

1030 IF NUMBERS(K) <= NUMBERS(K + 1) 
THEN 1070 

1040 TEMP = NUMBERS(K) 

1050 NUMBERS(K) = NUMBERS(K + 1) 

1060 NUMBERS(K + 1) TEMP 

1070 NEXT K,J 

1080 RETURN 
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We reversed the logic of the test in the IF state- 
ment, and then we used it to bypass the lines 
required to exchange the two numbers. This was 
done to keep the lines short in the printed copy. /f 
you have the SWAP command in your version of 
BASIC, you can use the following line 1030 in- 
stead: 


1030 IF NUMBERS(K) >NUMBERS(K + 1) THEN 
SWAP NUMBERS(K),NUMBERS(K + 1) 


Then, eliminate lines 1040, 1050, and 1060. 
The SWAP command works much faster than the 
three lines we used above and is therefore pre- 
ferred, if it is available in your BASIC interpreter. 

Note that we did not use the variable I as an 
index in this subroutine. The reason for this is that 
we left the original FOR before the loop had been 
completed. In most versions of BASIC, repeat use 
of an index variable in this fashion simply cancels 
the original loop. But this is not true of all lan- 
guages. In FORTRAN, for example, a loop index 
variable disappears completely at the conclusion 
of the loop, and cannot be re-used until the loop 
has been completed. Other languages may or 
may not have a similar restriction, so it is good 
programming practice to avoid the problem from 
the start and not use one variable for two pur- 
poses at a time. 

Next, we must enter the averaging routine. The 
only difference between the routine we need and 
the one we discussed earlier is that we must add 
the numbers in the array, rather than inputting 
them one at a time. This does not cause any prob- 
lems in the coding of the program though. To im- 
plement the averaging function, enter the following 
program lines: 
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2010 SUM = 0 

2020 FOR J = 1 TO LAST 

2030 SUM = SUM + NUMBERS(J) 
2040 NEXT J 

2050 AVERAGE = SUM/LAST 
2060 RETURN 


In this case, we can use J as a loop index even 
though we used it before in the sort subroutine. 
This is no problem, because the sort subroutine 
completed its loop before returning to the main 
program. Thus d is free to be used again. 

At this point, the program is complete. 
However, before you RUN it, SAVE it to your 
working disk. You might use a filename such as 
STATS to indicate its purpose. By saving the 
programm, you make sure that it is safe, in case 
of a major fault that might cause your computer 
to “go to sleep” all of a sudden. When you have 
SAVEd your program, make sure that your 
NUMBERS.DAT file is on the disk in the default 
drive and that your printer is turned on and 
connected, and then type in the command: 


RUN<return> 


The amount of time required for this program to 
run will depend on several factors, including the 
specific version of BASIC you are using, the system 
clock speed, and the characteristics of your operat- 
ing system. But regardless of variations in execution 
time, you should have obtained the same results. 

The largest amount of time was consumed in 
sorting the list of numbers. Even so, this did not 
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require too much time, after which the averaging 
process went quickly. Then, your printer (or screen, 
if you specified it) displayed the sorted list and other 
results. 

The original list of numbers was generated by the 
following BASIC program: 


10 OPEN 8,8,8,,NUMBERS.DAT,S,W” 
20 FOR FF1 TO 86 

30 N=INT(RND(1)*100000)/1000 

40 PRINT#8,N 

50 NEXT I 

60 PRINT#8,-1 

70 CLOSE 8 


This program produced numbers in the range 
00.001 through 99.999. If the random number 
generator was truly random, both the average and 
median values should have been 50.000. But due to 
the limitations of BASIC and the way it handles 
floating-point numbers, this was not the case. You 
should have found 86 numbers in the list. They were 
also correctly sorted into ascending order. How- 
ever, the average value was 55.4463372 and the 
median value was 56.127. This indicates that the 
random number generator, while not perfect, is not 
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doing badly. With a longer list of numbers, these 


values would have been closer to 50.000. 
In addition, BASIC may not have handled the 


numbers exactly. For example, the 70th number in 
the list was 88.387001. This number is still visible on 
the screen, if you used screen output. The problem 
is that the number extends beyond three digits past 
the decimal point. The reason for this is that BASIC 
handles floating-point numbers in binary, but con- 
verts them to decimal format for output. The 
conversion process is not always precisely correct, 
so slight errors of this type can appear. However, 
the problem is normally very minor, and can 
generally be ignored. 


Sector 3: The CHECKBOOK and PHONE- 
BOOK Programs 


The expanded CHECKBOOK program is included 
on the enclosed program disk. PHONEBOOK will 
be provided in your next module. Before we look at 
CHECKBOOK, however, a few words of discussion 
are in order. 

These programs are examples of database man- 
agers. That is, they are programs that permit the 
user to create, update, and maintain data (the 
“database”) and to create reports of desired infor- 
mation based on the data. The main base of data 
resides in a disk file, from which any desired data 
record may be extracted and manipulated at will. 
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These two programs have very limited utility, be- 
cause they are each dedicated to a specific kind of 
data base. This does not mean that they are 
useless. Both of these applications, as well as many 
others, can be readily handled with a general- 
purpose database manager program. Thus, if you 
expect to be handling a variety of different kinds of 
data in a number of different ways, and especially if 
you will be handling a number of large databases, 
we advise you to consider using a regular, 
commercially-available database manager program 
rather than designing a separate BASIC program 
for each new kind of data base. On the other hand, 
if you don’t expect to go beyond the level we have 
used in the past few modules, there will be no need 
for you to purchase such a program. The decision 
on whether or not to obtain such a program should 
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be based on the amount of use you would expect 
to get from it. 

The intended operation of both CHECKBOOK 
and PHONEBOOK has already been discussed in 
detail as part of the design phase of these programs. 
The expanded version of CHECKBOOK, on the 
enclosed program disk, was written to fit the design 
requirements. 

This program contains a number of errors of one 
sort or another. Also, you may have some ideas 
that would make the program run better for your 
purposes. As you modify the program to adjust its 
operation, you will gain a much clearer under- 
standing of its operation. 

In working on these two programs, you have 
learned a number of very useful programming 
techniques. Primarily, you have worked with file- 
handling techniques using random-access files, and 
with the design and handling of video displays that 
did not scroll off the screen. This kind of display is 
very often required in a wide variety of programs: 
the framework of the display remains in place, and 
the actual data to be displayed or edited are placed 
in appropriate locations on the screen. Then, data 
to be changed are updated in place on the screen, 
as well as in memory. This arrangement makes the 
display far more pleasing than a scrolling display, 
and much easier to follow as well. 

The use of random-access files is essential in 
handling any data base. Only random-access files 
permit any record in the data base to be located 
directly, then read, updated, and written back in 
place. Sequential-access files, such as the one we 
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used in our STATS program earlier in this track, are 
perfectly satisfactory for many applications. In the 
case of STATS, we wanted to read all of the data, 
and not write any. We did not care in what order 
the data had been recorded in the file. If we had 
wanted to write the sorted data back out to the 
disk, we would have opened a new sequential file, 
for output only, and written the data to the new 
file. 

This sort of access is unsatisfactory for any kind 
of database management program. It would require 
that you read an entire file into memory, update 
records in the order in which they appear, and 
write them out to another file. If the entire file won’t 
fit into memory at once (and it probably won’t), 
you can’t back up to an already-written record and 
change it. Instead, you would have to go through 
the entire file, and then go through it again to find 
the earlier record you need. 

The disadvantage of random-access techniques 
is that you, the programmer, must predefine the 
exact size of each record as well as the size and 
content of every field in each record. This allows 
greater flexibility, but it also requires more planning 
in the design phase. Therefore, when you are han- 
dling files in a program, use the access method and 
techniques that best suit your application; do not 
limit yourself to any one access method. 


Sector 4: Modifying the STATS Program; A 
Practice Problem 


We have included on the enclosed program disk a 
data file called NAMES.DAT. The names in this file 
are actually random sequences of letters forming 
character strings. Each name entry contains two 
character strings separated by a comma and a 
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space, in standard LAST, FIRST format. No middle 
initial is included. To mark the end of the file, the 
character string END appears after the last name. 

For this problem, modify the STATS program 
you typed in earlier, so that it will accept these 
names into a string array, rather than accepting 
numbers into a numeric array. A 100-name array 
will be sufficient to hold all names. 

Adjust your STATS program so that it will read 
the data file and then sort the names into de- 
scending order (reverse alphabetical order, from Z 
back to A). Of course, it would be meaningless to 
try to calculate the average or median values of 
such a list. Therefore, your modified program 
should not contain these operations. However, 
your program should still print out the sorted list of 
names and report the number of names it found in 
the file. We will provide a working version of this 
program and the correct results in your next 
module. 


Sector 5: Coding a Program From its 
Flowchart: A Practice Problem 


Figure 6-6 shows the flowchart of a program. This 
program is essentially a computerized version of the 
electronic “decision maker” toy, in which you press 
a button and two lights flash on and off alternately, 
until ultimately one remains on and the other stays 
off. The two lights are labelled YES and NO (or 
TRUE and FALSE, or some equivalent), and each 
light has a fifty-fifty chance to remain on at the 
end. 
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START 


REQUEST 
YES-NO 
QUEST ION 


INPUT QUESTION 
WAIT FOR 
SSRI Ea as 
Nos - 


GET RANDOM 
aaah BETWEEN 


Figure 6-6. The flowchart for the problem in Sec- 
tor 5. 


For this program, use the RND function to return 
a number between 0 and 1. Code the program in 
BASIC, first using one of the programming forms 
we supplied with this module, and then typing the 
coded program into your computer. (If you prefer 
to use another language for practice, by all means 
do so. But remember, our working example in the 
next module will, of necessity, be in BASIC.) 
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It is not necessary to actually type in a question to 
get a random answer; all that is required is to press 
the (return) key. The YES/NO question is adummy 
input, required to tell the computer when to get a 
random number. 

When you have completed coding this program, 
try it on your computer to make sure that it works 
as described. Then, try designing an additional rou- 
tine that will cause the answers YES and NO to 
flash alternately on the screen, gradually flashing 
slower and slower until the randomly selected an- 
swer finally remains fixed on the screen. 

We will have working versions of both of these 
programs on the program disk for your next mod- 
ule. In the meantime, try designing them on your 
own. If at any time you find yourself becoming 
frustrated, stop for awhile! Come back when you 
are feeling fresher. You will often find that taking a 
break will give you a clearer outlook on the prob- 
lem and allow you to get more work done than 
otherwise. If you find yourself completely stuck, 
don’t worry. Your next module will supply you with 
working examples of all of these practice programs. 
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